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ABSTRACT 


A scheme  is  described  for  enhancing  the  COMRADE 
(Computer-Aided  Design  Environment)  Data  Management 
System.  This  scheme  would  produce  benefits  in  data 
management  efficiency,  user  convenience,  power,  and 
cost  effectiveness  by  representing  the  data  structure 
of  a COMRADE  data  base  apart  from  the  data  records 
and  by  adding  a system  specifically  designed  to  handle 
pointer  information,  in  particular,  such  techniques 
would 


. reduce  COMRADE  use  of  disk  I/O  for  data  block 
relationships , 

. simplify  the  organization  and  administration 
of  the  data  base, 

. enable  the  use  of  a powerful  data-def inition/ 
data  manipulation  language, 

. enable  the  use  of  an  inferential  search 
mechanism,  and 

. permit  existing  programs  involving  pointer 

relationships  to  remain  essentially  unchanged. 

The  degree  of  effectiveness  achieved  under  this 
scheme  can  be  further  enhanced  by  giving  the  data  base 
administrator  a greater  role  in  developing  and  main- 
taining the  data  base  in  a way  to  capitalize  on  the 
greater  flexibility  provided. 

The  procedures  involved  in  implementing  the 
proposed  scheme  and  the  benefits  to  be  realized  from 
such  a scheme  are  illustrated  by  describing  a hypo- 
thetical COMRADE/GIRS  system.  GIRS  (Graph  Information 
Retrieval  System)  is  an  in-house  developed  system 
written  in  FORTRAN  that  is  particularly  efficient  at 
manipulating  pointers.  It  is  already  operable  on  the 
CDC  6700,  the  PDP-11/45,  and  the  UNIVAC  1108,  and  is 
easily  portable  to  other  machines. 
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INTRODUCTION 


The  COMRADE  (Computer-Aided  Design  Environment)  software 
developed  at  the  David  W.  Taylor  Naval  Ship  Research  and 
Development  Center  in  support  of  the  CASDAC  (Computer-Aided 
Ship  Design  and  Construction)  effort  being  conducted  by  NAVSEA 
(Naval  Sea  Systems  Command)  consists  of  three  major  compo- 
nents— the  COMRADE  Executive,  the  COMRADE  Data  Management 
System,  and  the  COMRADE  Design  Administration  System.^  This 
report  describes  a method  for  enhancing  data  managment 
efficiency,  user  convenience,  power,  and  cost  effectiveness 
of  the  data  management  component. 

The  concept  is  simple.  Under  the  present  COMRADE  arrange- 
ment, much  of  the  information  contained  in  a particular  data 
block  of  a common  data  base  is  irrelevant  for  a specific  task, 
since  a data  base  must  serve  different  users  having  different 
requirements.  B.  Thomson^  speaks  of  the  common  data  base 
used  for  ship  design  in  the  following  way: 


Gorham,  W.  and  T.  Rhodes,  "COMRADE,  Computer  Aided  Design 
Environment  Project,  An  Introduction,  DTNSRDC  Report  76-0001 
(Nov  1976) . A complete  listing  of  references  is  given  on  page 
111. 

2 

Thomson,  B.,  "Plex  Data  Structure  for  Integrated  Ship 
Design,"  Presented  at  the  1973  National  Computer  Conference, 
American  Federation  of  Information  Processing  Societies, 

New  York,  pp.  347-352  of  the  Proceedings  (Jun  1973). 


i 


"The  SDF  (Ship  Design  File)  solves  the  data 
communications  problem  by  providing  a single  common, 
current  compendium  of  design  information...  The 
various  design  disciplines  view  the  ship  from 
different  perspectives  and  require  common  data  to 
be  organized  in  a variety  of  different  ways.  The 
SDF  employs  a plex  structure*  which  relies  upon 
sundry  types  of  pointers  to  connect  data  blocks 
in  the  various  relationships  required  by  the  user 
engineers  and  the  applications  programs." 

The  necessity  for  providing  different  pointer  information 

for  each  user  results  in  the  data  base  becoming  large  and 

cumbersome  to  search.  Moreover,  once  the  structures  (Block 

Type  Definitions)  which  define  the  contents  of  the  data  blocks 

have  been  determined  and  used,  they  are  extremely  difficult  to 

modify.  Under  the  current  COMRADE  scheme,  pointer  searches 

and  updates  involving  pointer  searches  consume  a large  amount 

of  disk  I/O  in  traversing  non-hit  pointers,  since  each  of  the 

data  blocks  containing  relevant  pointers  must  be  brought  into 

main  memory  even  though  most  of  the  contents  are  unrelated  to 

that  search.  Such  a necessity  makes  it  impractical  for  the 

user  to  either  recognize  or  report  on  a large  file  structure. 

Moreover,  pointer  information  takes  up  space  better  reserved 

for  data. 

A scheme  is  available  which  can  nullify  these  problems. 
Under  this  scheme,  all  pointer  information  is  extracted  from 
the  data  blocks  and  collected  into  a common  area  which  can 
exist  either  as  part  of  the  data  file  or  as  a separate  file 


* A plex  structure  is  the  most  general  form  of  data  structure 
in  which  any  given  node  may  be  related  to  any  other. 


established  exclusively  for  pointers.  This  collection  of 
pointers  can  be  easily  traversed  or  manipulated  by  a system 
especially  designed  for  that  purpose. 

A data  file  could  hold  several  different  descriptions 
of  the  data  structure  (several  different  pointer  collections), 
including,  if  desired,  a complete  description  of  the  data 
base.  This  requirement  of  multiple  views  of  the  data  base 
is  discussed  in  Jefferson  and  Bandurski. 

"Different  users  desire  different  information 
from  the  database,  are  familiar  with  different 
naming  conventions  and  levels  of  detail,  are 
permitted  to  read  and  alter  different  parts  of 
the  database,  and  impose  different  types  of 
consistency  constraints  upon  the  database. 

It  is  convenient,  then,  to  have  different 
views,  or  descriptions,  of  the  same  database 
for  different  users.  Further,  a program  may 
remain  stable  as  the  database  structure  changes, 
if  the  program  is  provided  with  an  unchanging 
view  of  the  database. 

The  user's  view  of  the  database  may  be 
simplified  by  eliminating  unnecessary  re- 
lations, records,  and  fields — essentially, 
by  providing  him  with  a subset  of  the  data- 
base— and  possibly  by  renaming  the  remaining 
relations  and  fields." 

Under  the  approach  proposed  within  this  report*,  the  data 
records  would  be  maintained  separately  from  the  pointer- 
information  relating  to  the  data  records.  The  data  records 


* A network  mcdel,  not  the  relational  model  of  Bandurski  and 
Jefferson.  See  their  paper^  for  the  advantages  and  dis- 
advantages of  the  relational  model. 

^Bandurski,  A.  and  D.  Jefferson,  "Enhancements  to  the  Re- 
lational Model  for  Computer  Aided  Ship  Design,"  DTNSRDC  Report 
4759  (Oct  1975) . 

Bandurski,  A.  and  D.  Jefferson,  "Data  Description  for 
Computer-Aided  Ship  Design,"  DTNSRDC  Report  4759  (Sept  1975). 
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would  be  compressed  and  the  excluded  pointer  data  collected 
into  a concise  representation  of  the  file  structure  so  that 
a system  designed  for  graph  processing  could  operate  on  several 
pointer  relationships  without  accessing  the  data  blocks. 

Thomson  cites  the  need  for  a system  which  will  allow 
flexibility  in  referencing.  In  his  description  of  the  SDF 
he  has  this  to  say: 

"The  most  significant  characteristic  of  the  SDF 
is  that  most  data  elements  have  several  distinct 
relationships  to  other  data  elements.  For  instance, 
a piece  of  electronic  equipment  may  belong  to  a 
sonar  system,  may  be  located  in  the  Sonar  Control 
Room,  may  be  classified  in  weight  group  412,  and 
may  be  physically  connected  to  various  other  com- 
ponents in  the  sonar  system  and  in  the  electrical 
distribution  system,  the  water  cooling  system, 
and  the  fire  control  system.  The  data  structure 
must  allow  the  electronic  component  to  be  referenced 
via  any  of  the  above  relationships.  This  require- 
ment reflects  the  inclination  of  various  disciplines 
to  view  the  ship  from  different  perspectives,  and 
it  dictates  a high  degree  of  interconnectivity  and 
flexibility  within  the  SDF." 

Under  the  proposed  system,  the  cost  of  maintaining  the  data 
records  would  continue  to  be  shared  by  all  users,  but  the  cost 

I 

I 

of  maintaining  a particular  Data  Definition  Dictionary  (DDD) 
defined  by  the  Data  Base  Administrator  (DBA)  would  be  borne  by 
the  particular  individual  for  whom  it  was  developed,  thus  re- 
sulting in  a more  equitable  distribution  of  the  cost. 

\ A COMRADE  data  base  as  presently  structured  is  shown  in 


Figure  1. 


DATA  BLOCKS  CONTAINING 
POINTER  INFORMATION 


DIRECTORY 


BLOCK  TYPE 
DEFINITION 
TABLE 


INVERTED 

LISTS 


Figure  1 - Current  Structure  of  a COMRADE  Data  Base 

Under  the  proposed  system,  the  structure  of  this  same  data 
base  would  be  changed  as  shown  in  Figure  2. 


o 

□ 
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Figure  2 - Proposed  Structure  of  a COMRADE  Data  Base 

Note  that  the  only  component  affected  by  this  restructuring 
would  be  pointer  structure  and  its  attendant  subroutines. 


To  provide  maximum  flexibility  for  the  manipulation  of 
pointers  in  an  arbitrarily  directed  (plex)  graph,  an  efficient 
system  for  storing,  retrieving,  and  manipulating  information 
in  main  memory  is  needed.  Thomson  has  this  to  say  about  the 
data  structure  design  needs  of  ISDS  (Integrated  Ship  Design 
System),  a prime  user  of  COMRADE: 

"Early  experience  with  a list  structured 
Ship  Design  File  revealed  that  such  a structure 
was  too  restrictive  for  the  requirements  of 
ISDS... It  was  accepted  that  a very  gene«ti'plex 
structure  was  required." 

Several  systems  exist  which  might  be  applicable  for  use 
within  COMRADE  for  pointer  manipulation  (see  later  section  en- 
titled "Satisfying  an  Imprecise  Query");  however,  the  paged 
version  of  the  in-house  developed  system  known  as  GIRS  (Graph 
Information  Retrieval  System^  ^ is  ideal  for  representing  and 
processing  "plex",  or  arbitrary,  graph  structures.  Moreover, 
GIRS  can  be  adapted  to  different  computing  systems  quite 
easily,  and  is  currently  available  on  the  CDC  6700,  the  PDP- 
11/45,  and  the  Univac  1108.  For  these  reasons,  the  proposed 
scheme  is  described  in  terms  of  a hypothetical  COMRADE/GIRS 
configuration. 

GIRS  used  in  conjunction  with  COMRADE  offers  a number  of 
advantages : 


Berkowitz,  S.,  "Design  Trade-Offs  for  a Software  Associative 
Memory,"  DTNSRDC  Report  3531  (May  1973). 

® Zaritsky,  I.,  "GIRS  (Graph  Information  Retrieval  System) 
Users  Manual"  (to  be  published). 
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(1)  Dependence  on  disk  I/O  for  pointer  operations  is 
reduced,  which  results  in 

(a)  reduced  wall-clock  time  at  the  teletype  terminal, 

(b)  lowered  over-all  cost  of  program  execution,  and 

(c)  the  option  of  adding  an  efficient  pointer 
traversal  executive  routine 

(2)  Multiple  views  of  a data  base  are  supported,  so  that 
the  DBA  can  tailor  the  data  structure  to  each  appli- 
cation. 

(3)  A powerful  Data-Def inition  Language/Data-Manipulation 
Language  ( DDL/DML)  can  be  incorporated,  which  results 
in 

(a)  greater  convenience  in  querying,  manipulating, 
and  modifying  data  block  relationships,  and 

(b)  greater  convenience  in  inverting  pointers  to 
answer  different  types  of  queries 

(4)  Back  pointers  can  be  added  automatically 
These  advantages  are  not  without  cost; 

1.  Implementation  costs  are  incurred. 

2.  Some  additional  disk  space  is  needed. 

3.  Disk  space  becomes  fragmented  for  systems  such  as  the 
CDC  which  have  a fixed  PRO  size. 

For  the  CDC  6700  computer,  with  its  fixed  PRU  size  of  64 
words,  the  approximate  number  of  PRU's  needed  for  pointers  can 
be  determined  by  dividing  the  number  of  pointers  in  the  entire 
data  base  by  64.  For  data  bases  composed  mostly  of  data 
blocks  longer  than  one  PRU,  the  total  amount  of  disk  space 
required  under  COMRADE/GIRS  may  actually  be  only  slightly 
different  from  that  required  under  the  COMRADE  system. 

A brief  description  of  GIRS  follows,  after  which  the 
trade-offs  among  time,  memory,  disk  space,  and  flexibility 
will  be  considered. 
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OVERVIEW  OF  GIRS  (GRAPH  INFORMATION  RETRIEVAL  SYSTEM) 


ELEMENTS  OF  THE  GRAPH  STRUCTURE 

GIRS  is  a hashed-address  associative  memory  scheme  designed 
to  accommodate  the  insertion,  retrieval,  and  deletion  of  in- 
formation contained  in  arbitrary  graph  structures.  Under 
this  scheme,  information  is  stored  conceptually  as  primitive 
structures  called  node-link-node  triples  with  the  first  node 
called  the  source  node  and  the  second  node  called  the  sink 
node,  or  value,  as  indicated  in  the  following  diagram. 


Figure  3 - Node-Link-Node  Triple 

Under  a COMRADE/GIRS  system,  the  source  node  A would  represent 
the  parent  data  block,  the  sink  node  C would  represent  the 
sibling  data  block,  and  the  link  B would  represent  the 
associating  pointer  or  function. 

The  triple  can,  of  course,  be  combined  with  other  triples 
to  form  a more  complex  graph  structure.  The  triple  can  be 
a component  in  a list  (Figure  4). 


alternatively  drawn  as 


Figure  4 - Multivalued  List 

The  triple  can  also  be  a component  in  a string  (Figure  5). 


Figure  5 - Concatenated  Value  String 

If  the  triple  G,H,A  were  added  to  this  string,  each  triple 
would  then  represent  a component  of  a circuit. 


PAGED  (OUT-CORE)  VERSION  OF  GIRS 


There  are  three  versions  of  GIRS  currently  available. 

Two  are  designed  to  use  a working  space  or  buffer  which 
contains  the  entire  graph  structure  in  main  memory.  In  one 
of  these  two,  the  buffer  is  divided  into  four  separate 
arrays  that  store  the  node,  list,  conflict  list,  and  flag 
functions;  in  the  other,  the  four  functions  are  packed  into 
a single  array.  The  third  version,  a paged  (out-core) 
extension  of  the  one  which  packs  the  functions  into  a single 
array,  is  the  one  that  concerns  us  here.  It  is  this  version 
that  is  suggested  for  use  with  COMRADE. 

In  this  out-core  version  of  GIRS,  the  triple  is  assigned 
to  a page  that  can  extend  its  length  as  needed  by  a specified 
increment,  called  a continuant.  These  adjustable-length  pages 
exist  to  enable  information  to  be  logically  divided.  Each 
page  contains  one  or  more  logical  records  (continuants)  of 
uniform  length,  as  illustrated  in  the  following  diagram. 

page  1 PAGE  2 PAGE  3 PAGE  4 


A continuant  may  be  used  either  as  a logical  subdivision  of 
the  graph  on  that  page  or  merely  as  an  area  for  overflow  from 
the  previous  continuant.  Thus,  although  all  of  the  pages  have 
the  same  limit  as  to  the  number  of  source  nodes  they  may  con- 
tain, the  sets  of  source  nodes  on  the  different  pages  are  dis- 
joint. Each  continuant  contains  a subset,  which  may  or  may  not 
be  distinct,  of  the  set  of  source  nodes  assigned  to  the  total 
page.  GIRS  will  automatically  create  continuants  as  needed. 

By  assigning  an  individual  address  to  each  continuant,  the 
user  can  conveniently  partition  a graph  into  a number  of 
"local"  subgraphs.  "Localness"  of  a subgraph  may  be  defined 
in  a number  of  ways.  For  example,  all  descendants  of  a node 
comprise  a subgraph  of  "local"  character.  All  or  part  of  the 
nodes  in  a string  or  list  may  be  considered  local.  To  minimize 
thrashing  (excess  disk  1/0  due  to  a poorly  designed  data 
partition),  the  user  must  carefully  partition  the  graph  into 
local  subgraphs  which  may  be  placed  onto  separate  continuants. 
Note  that  the  DBA  is  responsible  for  partitioning  the  graph 
in  a way  that  will  make  optimum  use  of  the  local  quality 
of  a subgraph.  Although  thrashing  cannot  ever  be  completely 
eliminated  (unless  the  entire  graph  structure  can  be  stored 
within  the  buffer),  the  technique  of  partitioning  represents 
an  improvement  over  the  current  situation  which  can  result  in 
a new  data  block  having  to  be  brought  in  for  each  pointer 
access. 
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The  following  excerpt  from  Berkowitz^  indicates  some  of  the 
problems  involved  in  relating  the  graph  structure  to  the  paged 

r 

GIRS  architecture.  Consult  Berkowitz  for  a more  detailed 
description  of  local  graph  processing. 

"The  central  problem  is  to  determine  on  which 
page  one  should  place  a newly  created  node.  If 
the  program  is  creating  a list  of  names  of  major 
graph  localities,  each  new  node  should  be  on  a 
different  page  than  the  current  one,  since...  each 
page  will  have  the  capacity  to  contain  at  least  the 
beginning  of  a graph  locality.  On  the  other  hand, 
if  the  list  is  part  of  a hierarchical  directory,  then 
only  the  terminal  nodes  of  the  directory  should  be 
on  different  pages  than  the  current  one.  Similarly, 
if  the  program  is  setting  up  strings  to  operate  on 
a trace  mode,  then  the  newly  created  sink  nodes 
should  be  on  the  current  page  or  at  worst  on  few 
enough  other  pages  so  that  primary  memory  could 
contain  all  of  them.  More  generally,  graph  mani- 
pulations are,  in  part,  combinations  of  directory 
searches  and  string  traces.  While  a directory 
search  can  result  in  a separate  disk  access  to  a 
new  graph  locality,  it  is  most  desirable  that  a 
trace  take  place  within  a given  locality  on  one 
page.  For  example,  consider  a stack  search  which 
provides  the  information  to  continue  a trace.  In 
this  case,  the  stack  nodes  are  best  represented 
as  a list — i.e.,  a terminal  directory — on  a single 
page.  The  sink  node  addresses,  however,  are  in- 
tended to  represent  links  in  a single  graph  locality, 
and  hence  are  all  used  on  the  same  page.  If  the  link 
addresses  are  never  used  as  source  nodes,  their 
place  of  definition  is  irrelevant." 

The  DBA  also  determines  the  continuant  size  and  the 

maximum  number  of  continuants  to  be  resident  in  main  memory 

at  any  one  time.  The  length  of  the  continuant  determines 

the  maximum  number  of  unique  source  nodes  that  may  be  defined 

on  a given  page. 


j 
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RELATIONSHIP  OF  DATA  STRUCTURE  TO  GRAPH  STRUCTURE 


Under  COMRADE,  the  POINTER  is  stored  in  the  data  BLOCK  as  j 

a "data  value".  GIRS  would  represent  this  same  relational 
information  as  triple  (Fi'gure  6). 

ii  \ 

I I 

BLOCK  ' iMw  Mock  nam*  j ] 

1 j 

Figure  6 - GIRS  Representation  of  a | 

Data  Block  Relationship  ] 
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A relational  triple  such  as  that  shown  in  Figure  6 would  be 
packed  into  a single  word  of  the  GIRS  buffer.  Multivalue  lists 
which  can  expand  and  contract  in  size  dynamically  would  re- 
present pointer  arrays  and  would  require  one  extra  word  of 
overhead  just  as  at  present  under  COMRADE. 

Random  values  assigned  by  GIRS  to  BLOCK  and  POINTER  (names 
assigned  by  the  user)  serve  to  place  and  locate  the  relationship 
within  the  GIRS  buffer  under  a hashing  technique.  All  new 
block  names  are  assigned  a random  number  along  with  a cross- 
file reference  number  if  necessary.  The  cross-file  reference 
number  would  associate  a new  block  name  with  the  appropriate 
COMRADE  file  in  the  data  base.  If  the  new  block  name  is  a hit, 
its  random  number  is  used  in  retrieving  its  Hollerith  name  which 
will  be  stored  along  with  it  in  the  GIRS  buffer.  The  Hollerith 
name  will  then  be  given  to  the  COMRADE  Data  Storage  Facility 


(CDSF)^  which  will  bring  the  hit  block  into  the  COMRADE  buffer. 
The  procedure  is  discussed  in  greater  detail  later  under  the 
heading  "Implementation". 

The  GIRS  representation  for  both  the  intra-file  pointers  and 
the  cross-file  pointers  would  be  identical.  With  a paged  GIRS 
structure,  a DBA  could  set  up  cross-file  pointers  and  intra- 
file pointers  for  each  file  in  the  data  base  on  a single  page. 
This  setup  would  be  particularly  suitable  for  a hierarchical 
directory.  The  primary  effect  of  the  shift  of  emphasis  from 
the  file  structure  to  the  page  structure  is  that  the  Cross  File 
Reference  Table  (CFRT)  has  to  be  modified.  Under  the  present 
COMRADE  system  each  file  has  its  own  CFRT.  In  a COMRADE/GIRS 
architecture,  a single,  universal  CFRT  for  all  of  the  files 
in  a data  base  would  be  established,  as  will  be  discussed 
later  in  more  detail. 

TIME/SPACE/FLEXIBILITY/TRADE-OFFS,  COMRADE/GIRS  VERSUS  COMRADE 
DISK  USE 

Pointer  Traversal  under  COMRADE 

. COMRADE  Dependence  on  Disk  I/O 

As  already  noted,  under  COMRADE  the  relational  information 
about  a COMRADE  data  block  is  physically  a part  of  that  block, 
so  the  block  itself  must  be  in  main  memory  if  the  relationships 
of  that  data  block  with  others  are  to  be  determined.  Only  a 

7 

Bandurski,  A.  and  M.  Wallace,  "COMRADE  Data  Management  System  - 
Storage  and  Retrieval  Techniques,"  Presented  at  the  1973  National 
Computer  Conference,  New  York  (Jun  1973)  American  Federation  of 
Information  Processing  Societies  Proceedings,  pp.  353-357. 
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very  small  portion  of  the  data  blocks  of  a COMRADE  data  base 
may  reside  in  the  working  buffer  at  any  one  time  (only  20  may 
be  accommodated).  Other  data  blocks  not  in  the  buffer  may  be 
needed  to  complete  a traversal.  To  bring  a block  in,  one,  and 
sometimes  two,  disk  accesses  are  needed.*  The  disk  location  of 
the  desired  data  block  is  contained  in  a subdirectory,  and  when 
the  subdirectory  present  in  main  memory  is  not  the  one  that  has 
the  address  of  the  particular  block  in  question,  the  appropriate 
subdirectory  must  first  be  brought  in.  The  data  block  is  then 
accessed.  As  an  example  provided  later  will  demonstrate,  a 
pointer  search  involving  more  than  just  a few  pointers  will 
make  extensive  use  of  disk  I/O  under  the  COMRADE  system. 

. Cross  File  Pointer  Traversal  under  COMRADE 
* It  is  in  the  area  of  cross-file  pointer  chasing  that  a 

COMRADE/GIRS  combination  is  of  the  greatest  value.  Under 
COMRADE,  a pointer  chase  at  the  QUERY  language  level  can 
extend  to  only  one  other  file  at  a time.  Thus  if  the  user 
has  opened  PERMFILEl,  he  may  temporarily  open  and  access 
PERMFILE2  but  he  may  not  go  on  to  PERMFILE3.  He  must  first 
return  to  PERMFILEl,  after  which  he  may  then  go  to  PERMFILE3. 
This  procedure  is  both  tedious  and  time  consuming  as  the 
following  sequence  indicates; 


* In  the  unlikely  event  that  the  size  of  the  data  block  should 
exceed  the  size  of  the  COMRADE  I/O  buffer  and  that  the  desired 
element  should  not  be  included  in  the  retrieval  portion  of  that 
data  block,  a third  disk  access  would  have  to  be  made  to  obtain 

I the  relevant  portion. 

* 

i 
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1.  Close  PERMFILEl 

2.  ATTACH  PERMFILE2 

3.  Open  PERMFILE2 

4.  Read  from  PERMFILE2 

5.  Close  PERMFILE2 

6.  UNLOAD  PERMFILE2 

7.  Open  PERMFILEl 

Depending  upon  the  size  of  the  load  on  the  CDC  6700  computer 
system  and  the  size  of  the  file  to  be  attached,  the  response 
time  at  the  terminal  might  be  quite  slow. 

Pointer  Traversal  under  GIRS 

. General  Considerations 

Under  GIRS,  pointer  traversal  is  a relatively  quick,  flex- 
ible, and  efficient  operation.  Moreover,  since  GIRS  has  been 
developed  "in-house",  it  offers  DTNSRDC  users  the  added  ad- 
vantage of  ease  of  maintenance. 

One  of  the  main  reasons  for  selecting  GIRS  to  handle 
comrade's  pointer  chasing  would  be  for  the  reduction  of  disk 
I/O  GIRS  provides.  Retrievals  and  insertions  involving  disk 
I/O  are  relatively  slow  compared  to  those  performed  in  main 
memory  and — due  to  the  current  cost  of  channel  time — expensive. 

No  pointer  retrieval/manipulation  scheme  can  reduce  the 
amount  of  disk  I/O  required  for  reading  in  "hit"  blocks.  If  it 
were  feasible  to  maintain  the  GIRS  representations  of  the  entire 
data  structure  in  main  memory  at  all  times,  disk  I/O  for  pointer 
chasing  would  never  be  needed  and  only  the  in-core  version  of 
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GIRS,  with  its  resultant  lower  space  requirements,  would  be 
needed.  However,  since  this  is  not  always  possible  and  out-core 
storage  is  sometimes  needed,  the  use  of  disk  I/O  can  at  least  be 
kept  to  a bare  minimum  by  partitioning  the  data  base.  Somewhat 
less  optimally,  if  the  data  base  can  be  partitioned  so  as  to  com- 
bine on  a single  continuant  all  those  relationships  that  are  to 
be  used  together,  a single  disk  read  to  bring  that  continuant 
into  main  memory  will  suffice.  In  this  case,  a simple,  in-core 
GIRS  retrieval  would  serve,  instead  of  the  several  disk  accesses 
ordinarily  required  to  bring  into  main  memory  information  which 
is  mostly  irrelevant.  If  more  than  one  continuant  is  needed, 
the  DBA  must  be  clever  enough  to  partition  the  data  base  so  as 
to  reduce  the  number  of  disk  accesses  required  per  query.  In 
practice,  it  would  be  difficult  to  choose  a partition  so  awkward 
that  pointer  traversals  under  GIRS/COMRADE  would  result  in  as 
many  disk  accesses  per  query  being  needed  as  under  COMRADE  alone. 

The  paged  version  of  GIRS  allows  more  than  one  page  to  exist 
in  main  memory  at  a time.  Therefore,  depending  on  how  the  work- 
space has  been  allocated,  a continuant  of  a page  may  or  may  not 
have  to  be  swapped  into  main  memory.  If  GIRS  should  need  the 
space  occupied  by  a continuant,  and  should  find  that  the  con- 
tinuant had  already  been  modified  when  it  was  in  main  memory, 
the  worst  that  could  happen  would  be  that  the  continuant  would 
have  to  be  written  out  to  disk  before  a new  continuant  could 
be  brought  in.  However,  continuants  are  never  modified  as  a 
result  of  a query.  GIRS  will  allow  a page  to  grow,  continuant 
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by  continuant,  to  absorb  new  portions  of  a graph.  Note  that 
if  a retrieval  fails — either  because  of  the  absence  of  a block 
name  or  because  of  a misspelled  block  name — all  of  the  continuants 
of  a page  may  have  to  be  brought  into  main  memory  to  be  searched. 
Judicious  choice  of  page  size  should  minimize  the  number  of 
continuants  needed,  and  thus  minimize  GIRS  I/O. 

Part  of  the  design  philosophy  of  COMRADE  is  to  maximize  the 
use  of  a data  block  while  it  is  in  main  memory  and  to  thus 
forestall  the  need  to  bring  back  that  same  data  block  over  and 
over  again.  The  GIRS  philosophy  is  similar.  The  graph,  which 
represents  the  logical  structure  of  the  data,  should  be  parti- 
tioned onto  pages  in  such  a way  that  the  "localness"  of  the 
subgraphs  will  be  preserved.  In  other  words,  whenever  possible, 
subgraphs  should  be  maintained  on  the  same  page  and  on  the  same 
continuant , 

To  illustrate,  note  that  a graph  can  be  broken  up  into 
lists  and  strings.  A typical  multivalued  list  might  be 
structured  as  shown  in  Figure  7. 


Figure  7 - A Typical  Multivalued  List 


A String  might  assume  the  form  of  Figure  8. 
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A group  of  strings  may  have  a common  source  node,  as  indicated 
in  Figure  9: 


Figure  9 - A Collection  of  Length-One  Strings 
Having  a Common  Source  Node 


In  some  cases,  traversal  is  restricted  to  strings  or  to 
lists.  In  others,  traversal  may  span  total  subgraphs  of  a given 
string  length  and  list  depth.  In  the  latter  case,  it  is  to  the 
advantage  of  the  programmer  to  keep  such  a subgraph  on  a single 
continuant. 


. Cross-File  Pointer  Traversal  under  GIRS 
As  already  mentioned,  COMRADE  allows  only  one  file  to  be 
traversed  at  a time  at  the  QUERY  language  level.  Under  GIRS, 
there  is  no  such  limitation.  GIRS  can  handle  cross-file  pointers 
easily  as  intrafile  pointers,  since  a universal  Cross-File 
Reference  Table  would  be  set  up  and  the  cross-file  reference 
number  would  be  stored  as  part  of  every  value  (sink  node)  re- 
presenting a data  block.  This  feature  would  be  beneficial  for 
COMRADE  applications  involving  distributed  data  bases. 

Under  GIRS,  the  pointer  to  data  records  in  various  different 
files  may  be  traversed  by  a single  query,  using  little  if  any 
disk  I/O,  since  cross-file  and  inter-file  pointers  may  be 
mixed  on  the  same  GIRS  page.  This  capability  can  be  assured 
by  collecting  all  of  the  necessary  pointer  relationships  onto 
a single  or  a relatively  small  number  of  continuants.  Of  course, 
severe  thrashing  can  result  if  the  necessary  relationships  of 
a subgraph  are  scattered  across  many  continuants,  most  of  which 
are  not  in  main  memory  at  the  time  they  are  needed.  It  is 
up  to  the  DBA  to  make  sure  that  the  graph  structure  is  thought- 
fully prepared. 

RESPONSE  TIME 

Response  Time  of  a COMRADE  Retrieval 

A COMRADE  retrieval  is  heavily  dependent  on  disk  I/O,  which 
can  consume  a lot  of  wall-clock  time.  This  dependence  needs  to 
be  reduced.  COMRADE  permanent  files  are  stored  on  both  the  841 
and  844  disk  drives  for  the  CDC  6700  computer  system.  An  I/O 


21 


access  to  a CDC  844  disk  drive  will  generally  take  between  40 
and  1000  mill iseconds r depending  upon  the  amount  of  time  lost 
while  waiting  for  an  available  I/O  channel.  Although  statis- 
tics on  the  average  disk  I/O  service  time  for  the  CDC  6700 
computer  system  are  not  available,  those  for  the  CDC  6400 
computer  system  indicate  that  the  average  disk  I/O  service 
time  for  the  CDC  6400  computer  ranges  between  200  and  280 
milliseconds.  The  average  disk  I/O  service  time  for  the  CDC 
6700  computer  is  thought  to  be  comparable.  Average  access 
times  in  milliseconds  for  the  different  disk  drive  units  are 
provided  in  Table  1.* 

TABLE  1 - CDC  DISK  DRIVE  SERVICE  TIME  REQUIREMENTS 


(in  milliseconds) 


CDC  841 

CDC  844 

Average  positioning  time 

69.5 

30.0 

Latency  time  (50%  of  rotation 

12.5 

8.4 

time ) 

Time  to  read  one  sector  or  PRU 

3.6 

1.4 

Channel  wait  time  (range) 

0.0  - 960.0 

0.0  - 960.0 

Total  service  time  (range) 

85.6  -1046.0 

40  -1000.0 

* This  information  was  obtained  from  Kenneth  C.  Rieck  of  the 
Center . 
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Using  the  "Presidents"  Data  Base  (described  in  Appendix 
A)  and  operating  from  a 10-character-per-second  teletype 
terminal,  a COMRADE  query  of  the  form 

PRINT  STATE,  CAPITAL  .OF.  HEAD/ADMIN/PRESPTR/ADMIN/STATEPTR/ 
required  approximately  230  data  block  accesses  for  pointers. 

On  two  tries,  this  query  took  7-8  minutes.  On  an  earlier 
occasion,  involving  an  older  model  CDC  disk  drive  system,  the 
query  took  13  minutes.  Fifty  of  the  230  data  blocks  retrieved 
were  hits,  while  the  remaining  180  were  extraneous.  The  buffer 
size  was  set  to  1025  words,  which  allowed  as  many  as  16  data 
blocks  to  reside  in  main  memory  at  a time.  A table  has  been 
prepared  which  shows,  for  N = 2 subdirectories,  the  prob- 
abilities of  the  following  situations  and  the  number  of  disk 
accesses  needed  for  each.  (Of  course,  these  probabilties 
assume  a random  distribution  of  the  blocks  to  be  retrieved); 

1.  The  desired  data  block  is  already  in  the  buffer. 

2.  The  data  block  is  not  in  the  buffer  but  the  appropriate 
subdirectory  is. 

3.  Neither  the  desired  data  block  nor  the  appropriate 
subdirectory  is  in  main  memory. 


p 

Willner,  S.  et  al . , "COMRADE  Data  Management  System,"  Presented 
at  the  1973  National  Computer  Conference,  New  York,  (Jun  1973) 
American  Federation  of  Information  Processing  Societies,  1973. 
pp.  345-349. 
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TABLE  2 - PROBABILITY  OF  A DATA  BLOCK  OF  THE  "PRESIDENTS 
DATA  BASE  RESIDING  IN  MEMORY 


[- 

L ' 


Contained  in 

Main  Memory 

Number  of  Disk 
Accesses  Needed 
to  Retrieve  De- 
sired Data  Block 

Probability 
of  Situation 

Situation  1: 

Block 

0 

Pg=  (1024/64)/281=.057 

Situation  2: 
Subdirectory  but 
not  block 

1 

Ps=  (1-P3)/N=.471 

Situation  3; 
Neither  block 
nor  subdirectory 

2 

The  number  of  disk  accesses  likely  to  be  needed  per  data 

block  retrieval  is  computed  as  follows: 

E = P^=2(1-P^-P)  = 2-  P -2P 
s'  SB  S B 

where  P is  the  probability  that  the  data  block  is  in  main 
memory 

_ buffer  size/averaqe  data  block  size 
total  number  of  data  blocks  in  data  base 


P is  the  probability  that  the  subdirectory  is  in  main 
memory 


Number  of  subdirectories 


For  the  "President's"  Data  Base,  E = 1.4146.  Thus  there 
are  180E  = 255  unnecessary  disk  accesses.  I/O  time  is  computed 
as  follows;  T = number  of  data  blocks  retrieved  times  E times 
the  disk  I/O  service  time.  For  the  "Presidents"  Data  Base, 

T ranges  between  1.08  and  1.52  minutes.  The  time  required 


for  the  equivalent  operation  in  a COMRADE/GIRS  scheme  is 
discussed  in  the  next  section. 


One  final  remark.  Pg  was  computed  on  the  basis  of  random 
allocation  of  block  names  to  the  subdirectories.  If  the  user 
were  allowed  to  specify  to  the  lower  level  CDSF  routines  that 
certain  collections  of  data  block  names  should  be  kept  on  the 
same  subdirectory,  Pg  could  be  greater  and  both  E and  T could 
be  reduced.  The  argument  for  this  approach  is  analogous  to 
that  for  partitioning  the  data  block  representation  in  GIRS, 
and  will  not  be  pursued  further. 

Response  Time  of  a GIRS  Retrieval 

i 

I So  far,  there  have  been  no  timing  tests  performed  on  the 

* out-core  version  of  GIRS,  although  the  in-core  packed-word 

version  has  been  tested.  In  the  in-core  version,  a simple 
retrieval  for  a triple  (which  might  contain  pointer  or  other 

* information)  requires  78  microseconds,  a magnitude  three  orders 

I faster  than  that  required  to  access  the  844  disk  drives.  Other 

I retrievals  take  up  to  142.6  microseconds  (worst  case). 

i Average  insertion,  deletion,  and  retrieval  times  for  the 

1 

' present  unpaged  and  unpacked  version  of  GIRS  are  documented  in 

Berkowitz.^  Assuming  that  the  proper  page-continuant  already 
exists  in  main  memory,  similar  operations  under  the  out-core 
version  might  reasonably  be  expected  to  take  slightly  longer, 
since  relative  addresses  within  the  GIRS  buffer  would  have  to 
j be  resolved. 


The  disk  I/O  time  for  a query  under  COMRADE/GIRS  (T  ) could 

G 

be  determined  as  follows: 

T = (number  of  hit  blocks)  x E + (number  of  GIRS  continuants 
G 

brought  in)  x (disk  I/O  service  time) 

In  the  COMRADE  example  involving  the  "Presidents"  Data  Base 
(given  in  the  previous  section),  there  were  626  pointers  and 
274  data  blocks.*  Two  hundred  thirty  data  blocks  were  read 
in  to  obtain  the  50  desired  data  blocks  (180  data  block  re- 
trievals were  extraneous).  If  GIRS  were  to  be  used  along  with 
COMRADE,  this  entire  data  block  representation  could  be  con- 
tained within  main  memory,  thus  obviating  the  need  for  any 
I/O  for  GIRS.  If,  for  some  reason,  the  entire  data  base  did 
not  fit  within  main  memory,  disk  I/O  would  be  needed  to  bring 
in  the  necessary  continuants.  Even  so,  the  total  amount  of 
I/O  needed  would  be  substantially  less  than  that  required 
under  COMRADE  alone.  The  speed  advantage  of  GIRS  is  extremely 
query-dependent  and  would  be  even  greater  if  more  non-hit 
blocks  were  involved.  The  speed  advantage  for  a single  query 
is  expressed  as 

D 

(H  + C/E) 

where  D is  the  total  number  of  data  blocks  brought  into  the 
buffer  in  the  present  system 

H is  the  number  of  hit  blocks  for  the  query 

C is  the  number  of  GIRS  continuants  that  must  be 
brought  into  main  memory 

* These  figures  were  supplied  by  Stanley  E.  Willner,  developer 
of  the  "Presidents"  Data  Base. 
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For  this  example,  the  speed  advantage  would  be  D/H  or  (230/50) 
or  4.6,  since  the  entire  relational  structure  would  fit  entirely 
within  main  memory. 


UTILIZATION  OF  DISK  SPACE 

Data  Block  Size,  Percentage  of  Pointers  per  Data  Block, 
and  Fragmentation 

The  SCOPE  disk  operating  system  can  handle  words  only  in 
64-word  groups,  these  groups  known  as  physical  record  units 
(PRO'S).  As  a result,  any  record  written  out  to  disk  must  take 
up  some  multiple  of  64  words.  All  data  records  of  a size  from 
1 to  63  words  (not  counting  the  end-of-record  marker)  would 
require  the  same  amount  of  space  (64  words),  and  those  of  64- 
127  words  would  take  twice  that  amount  of  space,  and  so  forth. 
Thus  a great  deal  of  fragmentation — unused  but  available  space — 
could  result. 

At  the  present  time,  COMRADE  users  work  approximately  90 
percent  of  the  time  with  blocks  containing  from  20  to  50  words.* 
Thus,  so  far  as  space  allocation  is  concerned,  it  would  be  of 
no  great  advantage  to  them  to  have  the  size  of  these  data  blocks 
reduced  by  removing  pointers.  However,  future  plans  for  the 
use  of  COMRADE  envision  the  need  for  data  blocks  larger  than 
one  PRU.  The  question,  then,  is:  At  what  point  does  it  become 
advantageous  spacewise  to  compress  the  data  blocks  by  removing 
the  pointers  and  assembling  them  elsewhere  on  a file  of  their 

* Data  obtained  from  Bernard  M.  Thomson  of  the  Center. 
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own  or  at  the  end  of  the  data  file?  (Other  reasons  for  separ- 
ating the  pointers  are  discussed  elsewhere  in  the  section 
entitled  "Time/Space/Flexibility  Trade-Offs,  COMRADE  versus 
COMRADE/GIRS." ) 

In  the  current  COMRADE  scheme,  each  data  block  relation- 
ship takes  up  one  word  of  storage  plus  any  space  needed  for 
pointer  names  in  the  BTD  tables.  In  a COMRADE/GIRS  setup, 
one  word  is  needed  for  each  data  block  relationship  repre- 
sented by  a node-link-node  triple.  However,  additional  space 
is  needed  to  link  the  GIRS  random  number  representing  the 
sink  node  with  its  Hollerith  block  name  and  vice  versa,  since 
CDSF  cannot  use  the  GIRS  random  number,  and  the  block  name 
must  be  converted  to  a unique  random  number  to  be  operated 
on  by  GIRS.  Conversion  of  the  random  number  to  the  block  name 
requires  one  or  two  additional  words  per  name,  depending  on 
the  length  of  that  name. 

To  convert  the  Hollerith  name  to  its  associated  random 
number,  at  least  one  additional  word  per  block  name  is 
necessary;  however,  the  exact  amount  of  space  required 
varies.  The  less  the  correlation  among  the  block  names,  the 
greater  the  amount  of  space  required.  Thus,  the  three  names 
EQUIPl,  EQUIP2,  and  EQUIPS  will  require  less  space  than  the 
names  EQUIPMNT,  MACHINES,  and  MOTORS.  Block  names  in  COMRADE 
data  bases  generally  exhibit  a high  degree  of  correlation. 

This  will  be  discussed  in  further  detail  in  the  section 
entitled  "Implementation". 
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For  programs  needing  successive  runs,  additional  space  may 
be  needed  under  COMRADE/GIRS  to  store  the  values  of  nodes  and 
links,  depending  upon  which  of  two  methods  is  used.  In  the 
one  method,  all  of  the  nodes  and  links  are  written  out  to 
disk  at  the  end  of  the  program  and  then  read  back  in  at  the 
beginning  of  each  run;  in  the  other,  values  for  the  nodes 
and  links  are  reassigned  by  the  GIRS  pseudo  random  number 
generator  at  the  beginning  of  each  lun  (the  same  sequence 
of  values  will  be  used),  so  no  extra  storage  space  is  needed. 

The  disk  space  allocation  under  the  two  different  systems 
is  computed  as  follows: 

Under  the  COMRADE  system: 


Total  number  of  PRU's  = M 
Under  the  COMRADE/GIRS  System: 
Total  number  of  PRU's*  = M 


+ 


+ 3 


where  M = number  of  data  blocks 

w = average  number  of  words/data  block 
p = average  percentage  of  pointers 
[]  = greatest  integer  function  (i.e.,  3.8 ->3) 
c = total  number  of  continuants  for  all  pages 
h = nine  header  words/continuant 


* This  computation  includes  the  space  needed  to  store  data 
block  names. 
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From  the  expressions  just  given,  one  can  see  that  under  the 
proposed  system  a data  base  would  require  slightly  more  space 
than  under  COMRADE,  except  in  those  cases  in  which  the  data 
blocks  would  be  one  PRU  in  length.  If,  however,  a computer 
system  having  variable  length  PRU's  (such  as  the  IBM  disk 
operating  system)  were  to  be  used,  the  ratio  of  COMRADE  disk 
space  to  COMRADE/GIRS  disk  space  would  be  approximated  as 
follows ; 

^ COMRADE/GIRS  disk  space*  , ^ 2M+9C 

LJt'Qv-c  COMRADE  disk  space  Mw 


1 + - + 


9c 


w total  number  of  words  in 
orig.  data  base 

Let  us  now  determine  the  range  of  this  ratio  for  a ship 
described  in  a mature  data  base  of  the  Ship  Design  File.  A 
typical  data  base  in  this  case  might  consist  of  40  to  60  per- 
cent pointers.  We  have  chosen  a very  conservative  working 
space/available-space  ratio  of  7 to  3.  Furthermore,  as  an 
upper  bound  on  term  2/w  of  the  DSR,  the  number  of  elements  to 
be  included  per  data  block  has  been  set  at  nine.  Since  the 
latter  number  and  the  given  GIRS  ratio  are  unrealistically 
low,  values  thought  to  be  more  typical  will  also  be  considered. 
For  example,  the  average  number  of  elements  per  data  block 
might  more  reasonably  be  30.  Thus,  for  an  average  of  9-30 
elements  per  data  block,  the  term  2/w  would  then  range  from 
.22  to  .07.  Table  3 gives  the  DSR  for  six  different  cases. 


* This  number  includes  the  space  needed  to  store  the  data 
block  names. 
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TABLE  3 - DISK  SPACE  RATIO  (DSR) , COMRADE/GIRS  TO  COMRADE 
(Quantities  expressed  in  number  of  words) 


Number  of  attribute 
elements 

66000 

66000 

66000 

Number  of  pointer 
elements 

44000 

66000 

99000 

Total  number  of 
elements  in 
data  base 

110000 

132000 

165000 

Percentage  of 
Pointers 

40 

50 

60 

Continuant  size 

* 

100 

★ "k 

25 

★ 

100 

•k  k 

25 

★ 

100 

25 

Percentage  of  GIRS 
buffer  being 
used  (not  in 
Available  Space) 

85 

70 

85 

70 

85 

70 

Required  GIRS 
buffer  space 

51725 

62858 

77647 

94286 

116470 

141429 

Number  of 
continuants 
needed 

518 

2515 

111 

3772 

1165 

5658 

Third  term  of  DSR 

.04 

.21 

.05 

.26 

.06 

.31 

Minimum  DSR 

1.11 

1.28 

1.12 

1.33 

1.13 

1.38 

Maximum  DSR 

1.26 

1.43 

1.27 

1.48 

1.28 

1.53 

* Typical  case 
**  Conservative  case 


As  Table  3 shows,  the  third  term  of  the  DSR  equation  ranges 
from  .04  to  .31.  Therefore,  the  DSR  rartges  from  1.11  to  1.53, 
with  1.11  the  more  typical. 
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GIRS  Continuant  Size  and  Unused  Entry  Space 

The  continuant  size  must  be  determined  in  advance  by  the 
DBA.  The  hashing  scheme  employed  by  GIRS  results  in  the 
size  of  the  continuant  determining  the  maximum  number  of 
identifiers  or  node  and  link  names  that  can  be  created  for 
a page.  All  of  the  continuants  throughout  the  GIRS  structure 
of  a given  data  base  will  be  of  the  same  size. 

Under  GIRS,  the  use  of  many  small  continuants  rather  than 
a few  large  continuants  for  a given  size  graph  structure  might 
result  in  the  need  for  more  disk  I/O,  since  more  searching 
might  be  needed  to  find  a requested  relationship.  However, 
using  more  but  smaller-sized  continuants  could  result  in  a 
fuller  use  of  the  entry  space  in  GIRS.  If  the  continuants 
are  used  merely  to  store  overflow,  only  the  last  continuant 
of  each  page  will  have  any  unused  entry  space.  Moreover, 
with  the  GIRS  hashing  scheme,  any  partially  empty  continuants 
will  have  what  are  known  as  short  conflict  lists  which 
facilitate  quick  retrieval  response. 

Example  of  Disk  Use  under  COMRADE  and  under  COMRADE/GIRS 

The  following  example  compares  the  time  and  space  require- 
ments under  COMRADE  with  those  under  COMRADE/GIRS.  This  example 
illustrates  that,  when  the  search  path  of  a pointer  chase  ex- 
ceeds one  level,  COMRADE/GIRS  can  perform  the  query  in  less 
time  than  COMRADE  at  a cost  of  only  slightly  more  disk  space. 

In  the  nomenclature  of  COMRADE,  assume  three  pointer  arrays 
DECK(L),  COMPART(M),  and  EQUIP(N) — with  the  respective  lengths 
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L,  M and  N.  The  pointer  array  COMPART(M)  is  repeated  in  L 
different  data  blocks  and  the  pointer  array  EQUIP(N)  is 
repeated  in  LM  different  data  blocks,  resulting  in  LMN  number 
of  hits.  The  following  query  is  made: 

PRINT  COST  .OF.  SHIPl/DECK/COMPART/EQUIP 
Assume  also  1000  data  blocks  and  six  subdirectories.  Under  the 
COMRADE  system,  only  one  subdirectory  may  be  in  main  memory  at 
a time.  The  minimum  block  size  is  64  words,  and  the  COMRADE 
I/O  buffer  is  set  at  1281  words.  Therefore,  as  many  as  20  data 
blocks  may  be  in  main  memory  at  any  one  time.  The  following 
table  indicates  the  probability  of  the  desired  item  residing 
in  main  memory  and  the  number  of  disk  accesses  involved: 


TABLE  4 - PROBABILITY  OF  A DATA  BLOCK  OF  THE  TIME/SPACE 
EXAMPLE  RESIDING  IN  MAIN  MEMORY 


Possible  Situations 
in  Main  Memory 

Number  of  Disk 
Accesses 

Needed  to 

Retrieve  Desired 
Data  Block 

Probability  of 
Situation 

Situation  1 

Block 

0 

P =(1281/64)/1000=.02 

B 

Situation  2 
Subdirectory 
but  not  block 

1 

P =(l-.02)/6=.1633.  . . 

Situation  3 

Neither  the  block 
nor  the  sub- 
directory 

2 

‘■neither''!- <’2)  (5/6) 

= . 8166  . . . 
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The  number  of  disk  accesses  expected  per  data  block  retrieval 
E for  any  one  data  block  would  be  expressed  as 
2 - .1633. ..-(2  X .02)  = 1.7966... 

Under  COMRADE,  this  query  would  result  in  E( 1+L+LM+LMN) 
number  of  disK  accesses  where  E(0_<  E £2)  is  the  expected  number 
of  disk  accesses  per  data  block.* 

The  actual  number  of  disk  accesses  under  COMRADE  might  even 
be  greater,  since  the  COMRADE  buffer  may  contain  only  20  data 
blocks  at  a time,  forcing  certain  data  blocks  to  be  brought 
into  main  memory  more  than  once. 

In  the  GIRS  scheme,  the  contents  of  each  pointer  array 
are  represented  as  a multivalued  list.  The  data  block  names 
are  assigned  unique  "random"  numbers  which  are  represented 
by  dollar  ($)  signs.  For  example,  SHIPl  has  the  value 
The  COMRADE  pointers  DECK,  COMPART,  and  EQUIP  become  GIRS 
functions  or  links.  The  links  must  also  be  assigned  unique 
"random"  values.  The  GIRS  pointer  graph  would  have  to  contain 
the  following  structure  to  handle  the  query  of  the  example; 


I 

j 


* In  the  unlikely  event  that  the  data  block  size  should  exceed 
the  buffer  size  and  the  desired  element  were  not  present  in  the 
retrieved  portion,  then  0<E<3. 
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SHIP1 


EQUIP 


Figure  10  - GIRS  Structure  for  Example 


Using  COMRADE/GIRS , the  query  given  would  result  in 
L + LM  + LMN  GIRS  retrievals  to  traverse  the  graph,  and  LMN 
retrievals  for  the  Hollerith  representations  of  the  block 
names.  (Conceivably,  all  of  the  nodes  could  be  contained 
within  main  memory,  resulting  in  no  need  for  disk  I/O.)  The 
CDSF  routines  would  be  given  LMN  hit  block  names  which  would 
result  in  E(LMN)  disk  accesses,  thus  eliminating  the  need  for 
E(1  + L + LM)  disk  accesses. 

Clearly,  there  is  a potential  time — and,  therefore, 
cost — savings  under  COMRADE/GIRS,  due  to  the  reduced  need  for 
disk  I/O.  On  the  average,  the  time  savings  would  range  from 
.36(1  + L + LM)  to  .5(1  + L + LM)  seconds. 
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Under  the  present  COMRADE  system,  the  pointer  arrays  require 
L + L(M  + 1)  + LM(N  + 1)  words,  as  well  as  a small  amount  of 
additional  space  to  describe  them  in  the  Block  Type  Definition 
(BTD)  file.  In  comparison,  a COMRADE/GIRS  system  would  require 
somewhat  more  disk  space.  Recall  that  1000  data  blocks  exist 
in  the  data  base.  Under  this  GIRS  scheme,  at  least  (L  + 2)  + 

L(M  + 1)  + LM(N  + 1)  words  would  be  needed  to  store  the  graph 
that  describes  the  relational  structure  of  the  data  base,  as 
well  as  one  or  two  additional  words  for  each  data  block  name. 

For  each  partition  (continuant)  of  the  relationship  graph,  an 
additional  nine  words  for  GIRS  overhead  would  be  needed.  The 
out-core  version  of  GIRS  maintains  a directory  of  the  contin- 
uants that  are  in  main  memory  at  any  given  moment.  The 
directory  size,  which  is  determined  by  the  applications 
programmer,  is  set  at  one  more  than  the  first  multiple  of 
64  that  is  greater  than  the  number  of  in-core  continuants. 

A copy  of  the  directory  is  stored  on  disk  at  the  start  of 
the  program.  In  general,  the  directory  will  take  up  only 
one  or  two  PRU's.  For  example,  say  that  GIRS  used  the 
COMRADE  buffer  (1281  words)  for  its  own  buffer.  Even  if  the 
continuant  size  were  set  at  only  ten  words,  the  directory 
size  d would  be 


(l281  - 


1 


= 128  words  or  two  PRU's 
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Let  us  now  determine  how  much  extra  disk  space  would  be 
required  under  COMRADE/GIRS  for  the  same  graph.  If  L,  M,  N 


are  20,  30,  and  40  respectively,  and  if  the  continuant  size  is 
set  to  100,  the  directory  will  require  one  PRU  or  64  words. 

Let  us  also  assume  a 15  percent  available  space  in  the  GIRS 
buffer.  This  graph  would  then  require  a pointer  space  of  29697 
words,  requiring  297  continuants.  Accordingly,  the  COMRADE/ 

GIRS  system  would  take  1 + (9  x 297  + 200  + 64)/25242  words  of 
storage,  or  1.188  as  much  disk  space  as  under  COMRADE,  plus 
.15  of  that  amount  to  account  for  the  available  space  thereby 
totaling  1.388.  Of  course,  if  this  "data  base"  contained 
attribute  data,  that  ratio  would  be  lower.  For  example,  50 
percent  attribute  data  would  bring  the  ratio  down  to  1.169. 

CORE  REQUIREMENTS  FOR  COMRADE/GIRS 

The  out-core  version  of  GIRS  can  be  conveniently  separated 
into  two  parts,  a major  part  and  a minor  part.  The  major  part, 
which  takes  up  7350g  (3800)  words  plus  an  additional  110  words 
for  APAGE,  a CDSF  routine,  performs  all  of  the  main  functions. 
The  GIRS  buffer,  which  contains  the  in-core  portion  of  the  data 
block  relationship  graph,  would  not  use  up  any  additional  main 
memory  since  the  COMRADE  buffer  and  the  GIRS  buffer  would  share 
the  same  memory  space.  If  the  DBA  could  be  certain  that  the  re- 
lational information  would  fit  entirely  within  the  GIRS  buffer, 
only  the  in-core  packed  version  of  GIRS,  which  takes  up  about 


4300g  (2250)  words,  would  be  needed.  Even  if  GIRS  were  split 
up  with  about  3340g  (1760)  words  going  to  the  major  portion. 


i 


i 


the  major  functions  could  still  be  performed.  If  only  querying 


of  the  relational  structure  were  to  be  performed,  only  370g 
(250)  words  of  the  GIRS  package  would  be  needed.  A query  using 
the  out-core  version  of  GIRS  would  still  require  7350g  words. 

GIRS  is  a subroutine  package  which  requires  an  executive 
routine  to  create  the  subroutine  calls.  It  is  similar  to  Sub- 
routine QUERY  in  this  respect.  Subroutine  QUERY  handles  a 
parsed  ".WHERE."  clause,  whereas  this  new  executive  routine 
would  be  required  to  handle  a parsed  ".OF."  clause.  Since  an 
executive  routine  has  not  yet  been  written,  we  cannot  accurately 
gauge  its  size;  however,  a program  for  using  GIRS  interactively 
at  the  terminal  already  exists  which  takes  1060g  (560)  words. 
This  program  has  functions  similar  to  those  needed  by  an 
Executive  routine. 

The  amount  of  CDC  main  memory  available  to  an  applications 
programmer  is  limited  to  60Kg (24,600)  words  when  a remote 
terminal  is  used.  Currently,  27Kg  (11,800)  words  are  allotted 
for  COMRADE  functions,  although  plans  are  being  made  to  reduce 
this  size  to  20Kg  (8200)  words  in  the  near  future.  Also, 
approximately  IK  is  used  for  the  COMRADE  I/O  buffer. 

Since  COMRADE  is  being  revised,  information  is  not  yet 
available  as  to  the  amount  of  main  memory  to  be  required.  From 
the  numbers  just  discussed,  however,  we  can  state  that,  at 
worst,  GIRS  will  require  10,400g  (4360)  words.  COMRADE 

developers  feel  that  COMRADE/GIRS  will  fit  within  the  20K 
constraint. 
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FLEXIBILITY 


Modify  Data  Block  Relationships 

A COMRADE/GIRS  architecture  would  provide  a great  deal  more 
flexibility  in  handling  data.  Such  a system  would  enable  the  DBA 
to  create r update,  and  remove  all  or  any  part  of  a description 
of  the  data  base  with  relative  ease.  The  data  definition 
dictionary  could  be  created  and  modified  independently  of  the 
data  base  itself,  so  there  would  be  no  necessity  for  moving  data 
records  into  and  out  of  main  memory. 


Pointer  Traversal  Executive  Routine 

Currently,  COMRADE  allows  the  data  base  to  be  queried  at  two 
different  levels  - namely,  via  the  CDMS  subroutines  and  via  the 
QUERY  processor  - which  provides  the  user  with  flexibility/ 
convenience  trade-offs.  The  latter  level  accepts  English-like 


requests,  parsing  and  converting  them  into  CDMS  subroutine 
calls.  Although  COMRADE  already  has  an  inverted  query  exe- 
cutive routine  (called  QUERY) , it  does  not  have  a pointer- 
traversal  executive  routine.  The  advantage  of  such  a routine 
for  COMRADE  may  be  illustrated  by  a discussion  of  the  way  in 
which  COMRADE  presently  must  handle  the  following  three 
different  queries. 

1.  PRINT  BN  .WHERE.  AREA  .EQ.  20; 

2.  PRINT  COST  .OP.  BLOCK1/PTR1/PTR2 ; 

3.  PRINT  HEIGHT  .OF.  BLOCK2/PTR3/PTR4  .WHERE.  AREA  .GT.  1000; 


will  be  parsed  and  then  the  equivalent  code  to  Subroutine  QUERY 
(which  is  part  of  the  QUERY  processor)  will  be  called  to  bring 
in  and  search  the  inverted  lists  and  then  return  the  names  of 
the  data  blocks  having  AREA  = 20.  These  blocks  are  the  "hit" 
blocks.  The  query  could  also  have  been  handled  in  COMRADE  at 
the  lower  level  with  the  applications  programmer  calling  a 
COMRADE  executive  subroutine  (also  called  QUERY)  directly, 
supplying  input  parameters  in  the  equivalent  of  a parsed 
.WHERE,  clause.  This  method,  which  is  convenient  to  use, 
would  allow  an  applications  program  to  use  the  output  of 
the  Subroutine  QUERY  immediately. 

In  the  second  instance,  the  QUERY  processor  must  call  a 
series  of  routines  to  bring  in  BLOCKl  and  the  data  records 
associated  with  PTRl  and  PTR2 . The  applications  programmer, 
in  order  to  have  greater  flexibility  (for  example,  to  be  able 
to  use  the  retrieved  data  immediately  or  to  restrict  the 
pointer  chasing  to  blocks  found  in  the  nth  repeating  group) , 
will  have  to  make  several  subroutine  calls  for  a typical 
pointer  chase  query,  since  there  is  no  pointer-traversal 
executive  routine  currently  in  COMRADE  analogous  to  Subroutine 
QUERY  to  handle  the  parsing  of  an  .OF.  clause.  Under  the 

present  system  of  COMRADE,  use  of  a pointer  chasing  routine 

■ f 

I ^ 

would  be  inefficient,  since  hit  blocks  would  have  to  be  re- 
I moved  and  later  brought  back  into  main  memory  when  the  buffer 

j was  filled.  A pointer  executive  routine  under  a COMRADE/GIRS 

combination  would  accept  the  equivalent  of  a parsed  .OF.  clause 
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as  input.  The  first  input  parameter  (the  starting  data  block) 
would  be  treated  as  a source  node  and  the  rest  of  the  input 
parameters  (the  pointer  names)  as  link  names.  Output  would 
be  a list  of  (potential)  hit  blocks.  Therefore,  the  number 
of  hits  per  query  would  then  be  available.  This  same  type 
of  query  will  be  discussed  for  the  data  definition/data  mani- 
pulation (DDL/DML)  language  level  in  the  section  on  adding 
a DDL/DML  to  COMRADE. 

In  the  third  instance,  the  pointer  list  is  traversed  as 
in  the  second  instance,  resulting  in  a sequence  of  potential 
hits.  Each  of  these  potential  hit  blocks  is  brought  in  (along 
with  the  non-hit  blocks  needed  for  the  pointer  traversal)  at 
which  point  the  proper  attributes  are  tested  against  the  con- 
ditions of  the  .WHERE,  clause  to  determine  whether  or  not 
the  block  is  truly  a hit. 

As  already  mentioned,  most  of  the  disk  I/O  needed  under 
COMRADE  for  retrieving  the  non-hit  blocks  would  be  eliminated 
under  the  COMRADE/GIRS  scheme.  In  addition,  disk  I/O  use 
could  be  reduced  even  further  by  including  a pointer  executive 
routine  within  a COMRADE/GIRS  system.  Such  a routine  would 
bring  into  main  memory  only  those  potential  hit  blocks  which 
could  ultimately  satisfy  the  .WHERE,  conditions.  It  would 
accomplish  this  by  inverting  the  conditional  elements  involved 
in  a query  composed  of  both  .WHERE,  and  .OF.  clauses,  and  by 
then  ANDing  the  potential  hits  listed  by  the  pointer  executive 
routine  with  the  potential  hits  of  the  output  list  of  the 
.WHERE,  clause. 
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It  seems  clear  that  some  kind  of  a CDMS-level  routine  is 
needed  which  could  efficiently  handle  a parsed  .OP.  clause. 
The  COMRADE/GIRS  combination  could  satisfy  this  need,  as  is 
explained  later  on  in  the  section  entitled  "Implementation." 

Adding  a Data  Definition/Data  Manipulation  Language 
to  COMRADE 

Basically,  a Data  Definition  Language  (DDL)  is  used  to 
create  the  data  base  structure,  whereas  a Data  Manipulation 
Language  (DML)  is  used  to  access  and  modify  the  data  base. 

The  necessary  and  optional  characteristics  of  DDL/DML's  are 
detailed  in  Martin^  and  by  the  National  Bureau  of  Standards.^® 
A COMRADE/GIRS  system  would  enable  the  introduction  of  a 
concise,  powerful  DDL/DML,  since  GIRS  is  designed  for  pointer 
manipulation.  Structural  relations  described  by  a DDL/DML 
would  be  easier  to  visualize  and  therefore  easier  to  work 
with.  Because  the  one-to-one  correspondence  between  the 
pointer  relationship  and  its  DDL/DML  code  would  simplify  the 
conversion  of  the  conceptual  relational  graph  from  paper 
to  a DDL/DML  computer  program,  programming  time  would  be 
reduced.  Further,  a DDL/DML  would  allow  the  user  to  more 
easily  write  subroutines  capable  of  performing  such  functions 
as  deleting  a block  and  all  of  its  descendants  or  connecting 


9 

Martin,  J.,  "Computer  Data  Base  Organization,"  Prentice- 
Hall,  Inc.,  New  Jersey  (1975),  pp.  100-1. 

"CODASYL  Data  Description  Language,"  U.S.  Department  of 
Commerce,  NBS  Handbook  113,  (Jun  1973),  pp.  2.11-2.12. 
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a parent  of  a block  to  the  sons  of  that  block  when  that  block 
is  to  be  deleted. 

A particularly  convenient  DDL/DML  already  in  existence  is 
GIRL.^^  The  abstract  from  the  GIRL  Programming  Manual  follows: 

"GIRL  (Graph  Information  Retrieval  Language)  is  a 
programming  language  designed  to  conveniently  manipulate 
information  in  graph  structures.  As  such,  the  language 
will  play  a key  role  in  the  construction  of  the  organi- 
zational schemes  found,  for  example,  in  information 
retrieval,  pattern  recognition  problems,  linguistic 
analysis,  and  process  scheduling  systems.  The  language 
is  written  to  complement  an  algebraic  language,  in  the 
sense  that  GIRL  statements  are  distinguished  from  the 
statements  of  the  algebraic  language  and  the  statements 
may  be  interleaved.  The  primary  advantage  of  separating 
symbolic  and  numeric  statements  is  that  the  programmer  is 
afforded  a linear,  one-one  trace  of  graph  operations  in 
the  code  description." 

For  example,  using  GIRL  to  create  or  add  to  the  following 
structure  shown  originally  in  Figure  8, 


SHIP1 

the  following  code 

G SHIPl  DECKl  $ COMPRTl  $ EQUIPl  $ 
would  suffice.  To  find  the  EQUIPl  data  block  of  SHIPl,  the 
code 

G SHIPl  + DECKl  + COMPRTl  + EQUIPl 
might  be  used.  Modification  and  deletion  would  be  equally 
straightforward.  Further  examples  are  provided  in  the  section, 
"Pointer  Operations  under  COMRADE  and  under  COMRADE/GIRS" . 

Berkowitz,  S.,  "Graph  Information  Retrieval  Language;  Pro- 
gramming Manual  for  FORTRAN  Complement,"  Naval  Ship  Research 
and  Development  Center  Report  4137  (Jun  1973). 
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Note  that,  in  the  COMRADE  QUERY  language,  the  ".OF."  list 
for  a single  query  is  limited  to  eight  distinct  levels  of 
pointers  and  a total  of  16  pointer  accesses.*  This  limitation 
is  built  into  COMRADE  to  prevent  a pointer  chase  from  con- 
tinuously looping  on  a circuit.  Of  course,  at  the  CDMS  level, 
even  under  the  present  COMRADE  setup,  an  applications  programmer 
may  first  create  temporary  pointers  to  tag  data  blocks  as 
having  been  visited  and  them  remove  these  pointers,  although 
this  procedure  would  result  in  an  even  heavier  use  of  disk 
I/O  and  would  require  the  applications  programmer  to  generate 
several  CDMS  subroutine  calls.  Under  GIRS,  and  with  the  use 
of  a DDL/DML  such  as  GIRL,  it  would  be  a simple  matter  to 
temporarily  tag  a node  (data  block)  or  thread  a subgraph. 

The  previously  mentioned  limitations  would  no  longer  apply. 

GIRL  code  can  be  imbedded  within  a FORTRAN  program.  Although 
a preprocessing  step  would  be  necessary  to  translate  GIRL  to 
FORTRAN,  a GIRL  preprocessor  already  exists  which  is  portable 
and  currently  operational  on  the  CDC  6700  and  the  PDP-11/45. 
Moreover,  a GIRL/FORTRAN  compiler  is  already  being  written  for 
the  PDP-11/45. 

A single  GIRL  statement  can  take  care  of  either  a single 
CDMS  pointer  operation  or  a series  of  CDMS  pointer  operations 
that  ordinarily  require  several  lines  of  code  (See  Appendix  C). 


* COMRADE,  however,  does  not  permit  the  pointer  name  of  a level 
to  be  tacitly  repeated  if  the  sink  block  contains  the  pointer, 
giving  rise  to  a tree  of  pointer  strings. 
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Back  Pointers 


There  are  other  advantages  to  the  COMRADE/GIRS  combination. 

One  is  the  ease  of  adding  back  pointers.  This  could  be  done 
at  the  DDL/DML  level  with  the  following  statements; 

C ADD  POINTER  RELATIONSHIP 

-1  1 

G A B C : 

C ADD  BACK  POINTER  i 

G C B A 

These  two  GIRL  statements  can  themselves  be  combined 

G A B C B A i 

By  setting  a mode  flag  in  the  applications  program  to  .TRUE.,  j 

the  programmer  could  even  cause  back  pointers  to  be  created 
within  the  pointer  executive  routine  automatically.  This 
automatic  creation  would  continue  until  the  flag  is  changed 
to  .FALSE.  ! 

Pointer  Inversion  and  Query  Type  Specification 

The  preceding  discussion  has  shown  that  not  only  the 
question  A B ? but  also  the  question  C B ? can  be  answered.  ! 

What  about  the  questions  ? B C or  A ? C.  These  queries  might 
translate  to  "What  objects  have  DECKl?"  and  "How  are  ships  and 
decks  related?"  A COMRADE/GIRS  scheme  would  handle  these 
questions  by  hashing  (C,B)  and  (A,C).  A flag  would  be  set  to  j 

indicate  the  appropriate  query  type.  j 

At  the  cost  of  creating,  maintaining,  and  storing  some  ring  1 


storage  of  Nonpointer  Data 

GIRS  not  only  has  the  ability  to  store  and  manipulate 
pointer  relationships,  but  also  to  store  integer  and  Hollerith 
data.  Numbers  as  large  as  2^®  and  with  as  many  as  three  char- 
acters may  be  stored  directly  within  the  word  in  the  buffer 
that  holds  the  triple.  This  capability  would  be  valuable  to  a 
programmer  who  wanted  to  associate  a particular  relationship 
with  a subgraph  level.  Hollerith  and  integer  data  exceeding 
the  stated  limits  could  be  stored  in  a separate,  sequentially 
allocated  buffer  called  SEQSPC.  This  arrangement  provides 
space  for  the  rapid  retrieval  of  data  such  as  data  block  names. 

Satisfying  an  Imprecise  Query 

I 

Under  COMkADE,  an  engineer  wishing  to  locate  attribute 
data  stored  several  levels  below  his  starting  block  must  have 
knowledge  of  the  pointers  at  each  and  every  level  involved  in 
the  pointer  traversal.  All  of  the  pointers  must  be  specified 
to  satisfy  his  query.  This  situation  can  be  circumvented,  at 
the  expense  of  some  software  design  and  computer  time  and 
space,  by  having  the  DBA  provide  a generic  description  of  the 
data  structure  as  well  as  the  actual  data  structure,  as  illu- 
strated by  the  following  example.  , 

Let  us  say  that  an  engineer  wishes  to  query  the  structure 
of  Figure  11. 
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Figure  11  - Ship-Design  Data  Structure 

He  may  ask,  "What  types  of  structures  do  ships  have?"  This 
query  is  easily  answered,  since  "structures"  are  only  one 
level  below  "ships"  in  the  graph.  This  is  known  as  a direct 
query. 

But  what  if  he  wishes  to  ask  "Which  decks  do  ships  have?" 
This  query  could  not  be  satisfied  at  present,  since  "deck"  is 
more  than  one  level  below  "ships"  in  the  graph.  Since  "ship" 
and  "deck"  are  not  immediately  related,  this  query  would  be 
called  indirect.  An  indirect  query  could  be  handled  by 
allowing  the  GIRS  retrieval  routine  (FIND)  to  use  the  know- 
ledge of  the  different  types  of  permissible  relationships 
^in  the  graph.  Aside  from  the  data  base  itself,  an  indirect 
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query  also  requires  the  relationship  graph  and  a special  graph 
which  describes  the  data  structure  in  a general  way,  and  a 
method  of  searching  it.  This  special  graph  may  take  any 
number  of  forms,  depending  ^n  the  types  of  queries  expected. 

It  would  also  be  feasible  to  monitor  the  use  of  this 
mechanism,  allowing  the  program  to  create  direct  links  for 
commonly  issued  indirect  queries  which  could  then  be  answered 
directly. 

To  answer  questions  similar  to  the  engineer's  second 
query,  relationships  such  as  those  indicated  in  Figure  12 
would  have  to  be  added  to  the  relationship  graph. 


Figure  12  - Generic  Description  of  Ship  Design  Data  Structure 


r 
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Under  COMRADE/GIRS  each  user  would  design  his  own  search 
mechanism,  to  be  called  by  FIND  when  a direct  query  fails.  If 
he  did  not  wish  to  do  so,  his  query  would  be  unsuccessful.  An 
alternative  but  possibly  less  efficient  way  of  handling  this 
problem  would  be  to  permanently  embed  a general,  fixed  strategy 
into  the  system  which  would  require  only  that  the  applications 
programmer  submit  a list  of  relationships.  Such  a strategy 
might  perform  a level-by-level , breadth-first  search  of  the 
graph,  as  indicated  by  the  flowchart  of  Figure  13,  taken  from 
Ber kowitz . ^ 
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Figure  13  - Search  Procedure  for  an 
Indirect,  Memory-Related  Query 
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The  GIRL/PORTRAN  code,  also  from  Berkowitz,^  is  included  in 
the  Appendix.  Note  that  the  retrieval — or,  for  that  matter, 
the  insertion  or  deletion — strategy  is  essentially  embedded 
in  GIRS,  but  may  be  written  in  GIRL  (as  has  been  done  in 
Appendix  B)  for  descriptive  convenience. 

To  apply  the  algorithm  of  Figure  13  to  the  engineer's  in- 
direct query,  the  variables  A,  B,  and  C might  represent  ships, 
decks,  and  the  next  level  of  nodes  retrieved,  respectively. 

DOWN,  STRING,  and  REFER  are  used  as  reserved  GIRS  link  identi- 
fiers, and  LISTA  and  LISTB  are  reserved  GIRS  node  identifiers. 

This  procedure  is  guaranteed  to  work,  but  such  a "brute 
force"  method  may  take  excessive  time.  There  are  many  other 
procedures  available  which,  although  more  complex,  are  more 
powerful . 

There  are  various  languages  other  than  GIRL  which  might  be 
considered  for  use  with  COMRADE,  such  as  TRAMP,  for  example, 
which  possess  inferential  capabilities  but  are  relatively  in- 
flexible. This  inflexibility  is  due  to  the  use  of  a fixed 
predetermined  strategy  as  opposed  to  the  user-embedded  strategy 
of  GIRS/GIRL.  The  more  sophisticated  LISP-based  languages 
such  as  PLANNER  or  CONNIVER"^^  are  designed  to  handle  complex 

12 

Ash,  W.  and  E.  Sibley,  "TRAMP,  An  interpretive  Associative 
Processor  with  Deductive  Capabilities,"  Proceedings  of  the  23rd 
National  Conference  of  the  ACM,  pp.  143-156  (1968). 

13  . . . 

Hewitt,  C.,  "Description  and  Theoretical  Analysis  (using 

schemata)  of  PLANNER,"  MIT  Artifical  Intelligence  Laboratory 

AI-TR-258  (1972). 

14 

McDermott,  D.V.  and  G.J.  Sussman,  "The  CONNIVER  Reference 
Manual,"  MIT  Artificial  Intelligence  Laboratory  AIM-2599  (1974). 
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strategies  but  are  not  interfaced  with  a numeric  language  like 
FORTRAN  or  ALGOL,  and  are  relatively  non-portable.  On  the 
other  hand,  they  may  indeed  be  suitable  candidates  for  a DDL/ 

DHL  if  the  prime  emphasis  is  to  be  on  the  inherent  "intelli- 
gence" of  the  data  management  system.  For  a system  with  modest 
inferential  capability  and  relatively  low  overhead,  however, 
the  COMRADE/GIRS  combination  seems  preferable. 

There  are  other  types  of  indirect,  possibly  inverted, 
queries  which  the  engineer  may  wish  to  submit,  as  for  example. 

What  objects  have  the  structure  A? 

What  ships  have  the  structure  C? 

How  are  ships  and  decks  related? 

A different  algorithm  would  be  required  for  each  of  these 
queries. 

In  conclusion,  the  search  mechanism  of  the  proposed  system  i 

i 

is  a powerful  tool  which  would  provide  the  user  of  COMRADE  | 

with  a great  deal  of  flexibility,  even  though  it  would  require  j 

more  memory  and  additional  computing  time.  \ 


THE  ROLE  OF  THE  DATA  BASE  ADMINISTRATOR 


The  effectiveness  of  a data  base  is  largely  dependent  upon 
the  degree  of  involvement  of  the  DBA  in  coordinating  and  carry- 
ing out  the  design  and  maintenance  of  the  data  base.  A typical 
role  for  the  DBA  is  desribed  in  Bandurski  and  Jefferson.^ 

"The  data  base  administrator  plays  a key  role  in 
CAD  [Computer  Aided  Design] . He  must  design  and 
maintain  the  data  structures  used  by  a diversity  of 
designers  and  applications  programs,  so  must  be 
familiar  with  the  entire  design  process  as  well  as 
data  management.  Ideally,  he  should  provide  inter- 
faces to  protect  the  user  from  unnecessary  details 
of  programming  and  data  structures.  Each  user  should 
view  the  data  in  as  natural  a form  as  possible,  even 
though  the  actual  physical  structure  as  determined 
by  the  data  base  administrator,  is  quite  different. 

It  would  be  the  task  of  the  data  base  administrator, 
for  example,  to  provide  implicit  links  to  satisfy 
infrequent  queries,  and  highly  efficient  explicit 
links  to  provide  data  to  the  pre-programmed  analysis 
routines . " 

The  DBA  must  insure  that  the  logical  structure  is  designed 
to  allow  for  its  efficient  use  by  applications  programs. 
Specifically,  he  must  be  concerned  with  minimizing  the  operating 
cost  of  the  data  base  and  with  eliminating  unnecessary  I/O 
and  redundance  in  the  structure  while  still  accommodating 
different  views  of  the  data  base.  He  must  also  try  to  make  the 
interface  between  human  and  computer  as  smooth  as  possible. 

The  addition  of  GIRS  to  COMRADE  will  aid  the  DBA  in 
handling  these  problems.  Of  course,  the  DBA  will  have  to 
satisfy  certain  GIRS  parameters.  One  of  the  main  concerns  of 
the  DBA  will  be  to  determine  how  best  to  partition  the  graph 
onto  GIRS  pages  and  continuants.  This  involves  determining 
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an  optimum  continuant  size,  the  maximum  number  of  continuants 
to  be  in  main  memory  at  any  one  time,  and  also  which  (classes 
of)  relationships  are  to  reside  on  which  pages  and  continuants. 
Although  determination  of  page  and  continuant  residence  can  be 
left  to  default  (onto  a single  page  with  successive  continuants) 
fine-tuning  the  graph  partition  will  improve  performance.  This 
is  not  a trivial  task.  To  do  this  fine  tuning,  the  DBA  must 
design  a STRATEGY . This  is  described  in  the  section,  "Removal 
of  Pointers." 

The  DBA  will  perform  other  tasks  also.  He  must  determine 
what  extra  information  is  needed  to  answer  an  imprecise  query 
(see  section,  "Satisfying  an  Imprecise  Query")  and  whether  or 
not  the  ability  to  answer  it  is  worth  the  memory  cost.  It 
will  also  be  up  the  DBA  to  assign  a unique  identification  to 
every  file  associated  with  the  data  base,  since  the  Cross  File 
Reference  Table  must  be  unified  across  that  data  base. 

The  COMRADE/GIRS  system  offers  speed  as  well  as  an  option 
for  greater  flexibility  at  the  cost  of  more  storage,  a trade- 
off which  must  be  weighed  by  the  DBA.  The  DBA  would  be  charged 
with  making  the  applications  programmers  fully  aware  of  the 
potential  of  these  new  flexibilities. 


POINTER  OPERATIONS  UNDER  COMRADE 
AND  UNDER  COMRADE/GIRS 


This  section  compares  the  methods  of  performing  the  major 
operations  involved  in  creating  and  maintaining  a data  base 
under  the  COMRADE  system  and  under  COMRADE/GIRS.  The  following 
operations  are  considered: 

. Defining  data  structures 
. Loading  pointers  into  the  data  base 
. Updating  and  deleting  data  structure  components 
. Retrieving  data  from  the  data  base 
. Copying  all  or  part  of  substructure 
Under  COMRADE,  pointers  are  treated  in  much  the  same  manner  as 
alphanumeric,  integer,  real,  and  text  data.  Therefore,  many  of 
the  operations  described  will  hold  true  for  other  data  types. 


DEFINING  DATA  STRUCTURES 

The  data  structure  is  presently  defined  by  creating  data- 

block  formats  called  block  type  definitions.  The  following 

description  is  taken  from  Martin  and  Bell*'^,  page  16. 

"A  block  type  definition  can  be  defined  by  executing 
permanent  file  COMRDMDEFINEBLOCKTYPEABS  or  the  DEFINE 
BLOCK  TYPE  option  of  the  COMRADE  Command  Procedure 
BTMAINT. 

The  user  must  first  define  a suitable  data  structure. 
The  elements  must  be  logically  grouped  and  the  type  of 
data  each  is  to  contain  must  be  determined.  Names  and 
the  block  type  may  also  be  changed  but  elements  may  not 
be  reorganized,  deleted  or  added." 


Martin,  R.  and  C.  Bell,  "A  Primer  for  the  COMRADE  Data 
Management  System,"  NSRDC  Report  4605  (Jan  1975). 
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Under  COMRADE/GIRS  , the  data  structure  would  no  longer  need 
to  adhere  to  a rigid,  possibly  confining,  format.  The  data 
structure  for  each  relationship  would  be  defined  at  the  time 
the  relationship  was  added  to  the  graph  and  so  it  could  be 
easily  changed,  as  will  be  shown  in  a later  section.  If 
desired,  it  may  be  defined  prior  to  loading  via  a STRATEGY 
routine  called  by  the  GIRS  pointer  insertion  routine  INSERT. 

Use  of  STRATEGY  is  discussed  later  in  the  section,  "Conversion 
of  a Data  Base  for  the  COMRADE/GIRS  System." 

LOADING  POINTERS  INTO  THE  DATA  BASE 

Under  the  COMRADE  system,  the  Bulk  Data  Loader  performs  the 
initial  loading  of  the  data  base.  The  Loader  can  also  add  new 
data  blocks  to  an  existing  data  base. 

To  add  the  relationships  of  Figure  14  to  the  data  base,  the 
format  in  Figure  15  would  be  used. 

PTB1 


PTR2 

NXTBLK1 

NXTBLK2 

o NXTBLKN 

Figure  14  - BLOKl  - PTR  Relationships 
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BLOCK  NAME  - BLOK1 


•lemant  name  PTR1  (from  the  block  type  definition-btd/ 

NXTBLOK,  permanent  file  name 

element  name  PTR2  (from  the  btd)/dimention/pointer 
value  list 

Figure  15  - Format  of  Input  to  Bulk  Data  Loader 

Briefly,  the  Bulk  Data  Loader  builds  the  data  base  by  first 
creating  a skeleton  file  for  items  such  as  a directory,  sub- 
directory, inverted  name  list,  reallocation  table,  using  Sub- 
routine DEFIL.  Next,  Subroutine  DEFINB  creates  a skeleton  data 
block.  The  interpreter  (LOADB)  then  calls  LDEL  or  LDRG,  de- 
pending upon  whether  or  not  the  element  to  be  loaded  is  part 
of  a repeating  group.  Either  of  these  two  routines  will  call 
on  PTR  and  then  CHANGE  to  add  the  pointer  to  the  data  base. 

If  a cross-file  pointer  is  to  be  inserted,  PTR  will  call  PFNIN. 
PFNIN  returns  a cross-file  pointer  value  for  the  specified 
permanent  file  name.  It  will  create  this  value  if  one  does  not 
already  exist. 

Creating  the  pointer  structure  with  COMRADE/GIRS  would  best 
be  accomplished  with  the  use  of  a DDL/DML  such  as  GIRL.  First, 
the  user  would  declare  a continuant  size  and  an  initial  number 
of  pages.  Next,  the  user  would  declare  all  of  the  blocx  names 
(nodes)  and  pointer  element  names  (links)  in  a DEFINE  statement. 


■( 


The  nodes  and  links  would  be  assigned  unique  sequence-dependent 
"random"  numbers  which  the  user  would  either  store  or  regenerate 
for  future  update  runs. 

The  user  would  then  be  ready  to  create  the  relationship 
graph.  To  insert  the  first  relationship  (referred  to  in  Figures 
14  and  15),  in  which  the  element  name  is  PTRl , the  following 
GIRL  code  would  be  required: 

G BLOKl  PTRl  NXTBLOK 

FORTRAN  code  can  be  interleaved  with  GIRL  code,  allowing  for 
attendant  logic  or  calls  to  the  CDMS  subroutines.  A multivalue 
list  (pointer  array),  where  the  element  name  is  PTR2,  would  be 
inserted  similarly  with  the  following  code: 

G BLOKl  PTR2  ( NXTBLKl , NXTBLK2,...) 

The  GIRL  preprocessor  would  then  convert  these  statements 
into  FORTRAN  calls  to  Subroutine  INSERT.  An  entire  FORTRAN 
program  would  then  be  created  by  the  preprocessor  and  executed 
by  the  user.  Let  us  say  that  the  continuant  size  had  been  set 
to  500  words,  and  that  BLOKl,  PTRl,  and  NXTBLOK  had  been 
assigned  the  random  numbers  326,  205,  and  92,  respectively. 
INSERT  would  then  determine  the  necessary  offset  for  placing 
92  in  the  GIRS  buffer  by  computing  (326+205)  MOD  500.  It  would 
then  determine  the  appropriate  page  and  continuant  to  receive 
this  value  by  extracting  a non-zero  page  and  continuant  number 
from  BLOKl,  or,  if  the  page  number  had  not  yet  been  defined, 
by  calling  a user-defined  STRATEGY  for  page  definition.  If 
the  user  defaulted,  the  triple  would  be  placed  on  the  page 


I 


and  continuant  last  used.  For  further  details,  consult 

5 

Berkowitz. 

UPDATING  AND  DELETING  DATA  STRUCTURE  COMPONENTS 

Under  COMRADE,  there  are  three  methods  of  modifying  and 
deleting  (pointer)  data.  In  the  first  method,  a user  calls 
the  CDMS  subroutines  directly.  In  the  other  two  methods,  the 
subroutines  are  called  either  by  the  INTERACTIVEUPDATE  pro- 
cedure or  by  the  Bulk  Data  Modifier.  All  these  methods  call 


1 following 

CDMS  subroutines: 

CHANGE 

Adds  or  modifies  non-repeating  group 
elements  of  an  existing  data  block. 

CHANGO 

Changes  values  in  an  occurrence  of  a repeat- 
ing group  in  an  existing  data  block. 

ADDO 

Adds  a single  occurrence  of  a repeating 
group  in  an  existing  data  block. 

ADDU 

Creates  a locally  defined  element  to  a data 
block . 

DELETE 

Deletes  the  value  of  an  element  in  a speci- 
fied block. 

The  following  example  illustrates  the  way  in  which  a 
request  to  change  a block  name  (sink  node)  is  handled  under 
COMRADE.  Assume  that  the  data  block  EQUIPl  contains  a WEIGHT 
pointer  to  the  data  block  BLOK05,  and  that  we  desire  to  have 
it  point  to  BLOK07  instead.  The  parameters  to  CHANGE  (ICODE, 
IBN,  ISBN,  lEN,  DATA)  are  set  as  follows: 
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ICODE  = 0 (does  not  have  to  be  set  for  this  example) 
IBN  = 6HEQUIP1 
ISBN  = 4HSUB1 


5 


lEN  = 6HWEIGHT 


DATA  = 6HBLOK07 


Under  GIRL,  this  same  request  would  look  as  follows; 

G EQUIPl  WEIGHT  -.1  BLOK07 

(Note  that  under  COMRADE/GIRS , the  parameter  ISBN,  which  refers 
to  the  subblock  number,  is  not  needed  for  pointer  updates.) 

The  GIRL  preprocessor  would  convert  this  code  into  a call 
to  the  GIRS  subroutine  INSERT. 

This  request  to  change  a block  name  could  also  be  handled 
by  the  routine  PTREXEC,  described  later  in  the  section  which 
discusses  the  conversion  of  a data  base  to  the  COMRADE/GIRS 
system.  Parameters  for  PTREXEC  would  be  the  same  as  for  CHANGE, 
except  that  ISBN  would  be  replaced  by  an  operation  code  which, 
for  this  example,  would  be  eight.  The  relationship  in  question 
can  be  deleted  with  the  following  GIRL  code; 

G EQUIPl  - WEIGHT 

Before  a GIRS  operation  can  be  performed,  all  nodes  and 
links  must  be  defined  — that  is,  be  given  unique  numeric  re- 
presentations. Any  previously  defined  nodes  and  links  must  have 
their  old  values  returned,  and  new  nodes  and  links  must  be  de- 
clared in  a DEFINE  statement.  The  user  may  store  the  old  values 
on  disk,  or  he  may  redeclare  the  old  nodes  and  links  following 
the  same  sequence  as  that  used  originally  for  the  creation  of 
the  data  structure. 
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RETRIEVING  DATA  FROM  THE  DATA  BASE 


Retrieval  at  a Higher  Level 

Data  can  be  retrieved  from  a COMRADE  data  base  at  either  of 
two  different  levels,  a convenience  which  affords  the  user  a 
flexibility  versus  convenience  trade-off.  The  higher  level 
offers  more  convenience  for  simple  requests;  the  lower  level 
offers  fewer  restrictions.  At  the  higher  level,  the  QUERY  pro- 
cessor parses  English-like  requests  from  a remote  terminal 
and  converts  them  into  CDMS  subroutine  calls.  All  possible 
hits  are  returned  to  the  terminal.  If  the  programmer  wishes 
to  make  further  use  of  the  values,  he  must  re-enter  them  into 
the  machine.  Moreover,  he  may  not  restrict  a search  to  specific 
occurrences  of  repeating  groups  or  to  non-repeating  group 
elements . 

The  queries  are  basically  of  three  different  types: 

1.  Query  on  condition. 

2.  Query  via  pointers. 

3.  Query  on  conditional  values  returned  via  pointers. 

The  examples  provided  earlier  for  each  of  the  three  types  in 
the  section  entitled  "Pointer  Traversal  Executive  Routine" 
are  repeated  here  for  convenience. 

1.  PRINT  BN  .WHERE.  AREA  .EQ.  20; 

2.  PRINT  COST  .OF.  BLOCK1/PTR1/PTR2 ; 

3.  PRINT  HEIGHT  .OF.  BLOCK2/PTR3/PTR4  .WHERE. 

AREA  .GT.  1000; 

A brief  description  of  the  COMRADE  method  of  handling  these 
queries  has  already  been  given.  Under  COMRADE/GIRS , operations 


For  queries  of  the  second  type,  the  calls  to  FETCH  to  bring 

into  main  memory  each  and  every  data  block  involved  in  the 

search  would  no  longer  be  made,  since,  under  a COMRADE/GIRS 

system,  a pointer  chase  could  be  processed  largely  in  main 

memory  via  a single  call  to  the  pointer  traversal  executive 

routine  PTRCHSE.  PTRCHSE  would  convert  an  .OF.  list  from  a 

query  to  a series  of  calls  to  the  GIRS  retrieval  routine 

FIND.  For  example,  the  query 

PRINT  COST  .OF.  BL0CK1/PTR1/PTR2 

would  be  handled  as  follows; 

C NODE  = BLOCKl 
LINK  = PTRl 

CALL  FIND  (NODE,  LINK,  VALUE) 

NODE  = VALUE 
LINK  = PTR2 

CALL  FIND  (NODE,  LINK,  VALUE) 

C VALUE  NOW  CONTAINS  THE  NAME  OF  THE  HIT  BLOCK 
IBM  = VALUE 

CALL  FETCH  ( . . . ,IBN, . . . ,DATA, . . . ) 

PRINT  DATA 

If  either  PTRl  and  PTR2  were  pointer  arrays,  PTRCHSE  would 
generate  stacks  to  handle  the  situation.  Also,  as  a worst 
case  for  the  present  system,  if  a pointer  chase  were  to  be 
j expanded  to  its  maximum  of  16  levels,*  resulting  in  a single 

hit  block,  and  if  the  pointer  relationships  were  partitioned 
properly  in  a GIRS  graph,  there  would  be  as  much  as  a 16  to 
1 reduction  in  the  use  of  disk  I/O. 

Another  restriction  under  COMRADE  * prevents  a query  from 
extending  to  more  than  one  other  file  at  a time.  It  does  so 


; * This  restriction  holds  only  for  the  Query  processor  of 

i COMRADE . 
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in  a manner  described  in  the  section,  "Cross-File  Pointer 
Chasing  in  COMRADE."  In  contrast,  COMRADE/GIRS  would  treat 
cross-file  pointers  in  the  same  way  as  it  treats  intra-file 
pointers . 

Under  COMRADE,  a type-3  query  would  require  the  QUERY 
processor  to  first  perform  a pointer  chase  (again  bringing  in 
all  data  blocks  involved  in  the  traversal)  and  to  then  test 
the  specified  values  from  the  "hit"  blocks  against  the  con- 
ditions of  the  .WHERE,  clause.  Thus  an  inordinate  amount  of 
disk  I/O  would  be  used,  both  for  pointer  traversals  and  for 
those  "hit"  blocks  which  subsequently  proved  not  to  contain 
any  values  that  satisfied  the  .WHERE,  condition. 

A COMRADE/GIRS  system  would  avoid  this  excessive  use  of 
disk  I/O  in  the  following  manner.  All  values  to  be  condi- 
tionally tested,  such  as  those  returned  by  a type-3  query 
would  be  placed  on  the  inverted  list  so  that  they  could  be 
treated  as  queries  of  the  first  type.  Thus  a type-3  query 
would  result  in  two  lists,  one  with  the  names  of  all  the  hit 
blocks  from  the  pointer  chase,  and  the  other  with  the  names 
of  only  those  data  blocks  having  values  satisfying  the  .WHERE, 
condition.  By  ANDing  these  two  lists,  the  names  of  only  those 
blocks  actually  qualifying  (to  be  brought  in  by  FETCH)  would 
be  obtained. 

Retrieval  at  a Lower  Level 


At  the  lower  level,  none  of  the  restrictions  associated 
with  the  QUERY  language  would  apply.  The  user  would  set  up 


the  necessary  logic  and  then  call  the  CDMS  routines  himself. 


Following  are  the  major  CDMS  retrieval  subroutines. 

FETCH  Retrieves  the  value(s)  of  a single  element, 
array,  or  repeating  group. 

FETCHR  Retrieves  the  values  from  a set  of  repeating 
group  elements. 

FETCHN  Retrieves  the  values  from  a set  of  non- 
repeating group  elements. 

QUERY  Returns  the  hits  from  a .WHERE,  clause  (this 
subroutine  is  not  to  be  confused  with  the 
QUERY  processor) 

Suppose  that  a programmer  wishes  to  determine  the  block 
name  in  that  EQUIP  block  which  is  pointed  out  by  the  pointer 
WEIGHT,  as  shown  in  Figure  16. 


WEIGHT 


EQUIP  7 

Figure  16  - EQUIP-WEIGHT  Relationship 


He  might  use  the  following  code  in  calling  FETCH. 

IBN  = 5HEQUIP 

ISBN  = 1 

IRGN  = 0 

IRGR  = 0 

lEN  = 6HWEIGHT 

LENGTH  = 1 

CALL  FETCH  ( lERR, IBN , ISBN , IRGN , IRGR, lEN , DATA , LENGTH ) 
FETCH  would  bring  the  EQUIP  block  into  main  memory  and  return 
a block  name  in  the  DATA  parameter: 

DATA  = 6HBLOK20 

If  the  programmer  uses  the  PTREXEC  facility,  code  such 
as  the  following  might  be  used: 
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IBN  = EQUIP 

lEN  = WEIGHT 

lOP  = 5 

CALL  PTREXEC  ( lERR, IBN, lEN, lOP, DATA) 

PRINT  DATA 

The  GIRL  code  for  this  retrieval  would  be 

G EQUIP  + WEIGHT'  DATA 

PRINT  DATA 

COPYING/SEARCHING  ALL  OR  A PART  OF  A SUBSTRUCTURE 

As  already  mentioned,  under  the  present  COMRADE  system,  one 
and  sometimes  two  disk  accesses  are  required  to  bring  a needed 
association  into  main  memory.  Consequently,  any  program  which 
must  copy  all  or  any  part  of  a substructure  becomes  seriously 
I/O  bound.  Under  paged  GIRS,  on  the  other  hand,  and  assuming 
that  the  structure  has  been  skillfully  enough  partitioned  so 
that  the  desired  portion  (substructure)  of  the  graph  is  con- 
tained on  a single  continuant  or  page,  the  copy  operation  con- 
sists merely  of  indicating  the  appropriate  page  and  continuant 
number  of  a user-callable  GIRS  report  generator,  LVDUMP.  Each 
desired  continuant  is  then  transferred  with  a single  FORTRAN 
READ  followed  by  a WRITE. 

If  the  user  wishes  to  take  advantage  of  Subroutine  LVDUMP, 
but  finds  that  the  graph  has  not  been  properly  partitioned  be- 
forehand to  have  the  desired  information  isolated  on  a single 
page,  additional  steps  must  be  performed.  Two  of  the  methods 
available  for  performing  these  steps  are  particularly  suited 
for  use  with  GI.'S  because  they  are  essentially  in-core 
operations  and  offer  trade-offs  as  to  time,  flexibility,  and 
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space.  Both  methods  require  an  entry  point  to  the  graph 
(starting  node).  (Note  that  these  two  methods  apply  for 
searching  through  a graph,  also.)  The  first  method  requires 
the  user  to  supply  a stack  of  pointers  or  link  names  at  run 
time.  Portions  of  this  method  form  the  basis  for  all  three 
versions  of  Subroutine  DELEQ,  listed  in  Appendix  C.  The 
flow  of  operation  of  this  first  method  is  indicated  in  Figure 
17.  NODSTAK  temporarily  stores  the  values  or  sink  nodes 
encountered . 


Figure  17  - Algorithm  for  Copying/Searching 
Tree-Structured  Data 
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Under  the  second  method,  although  it  is  more  costly  in 
terms  of  space,  links  need  not  be  supplied  at  run  time,  since 


the  programmer  will  already  have  supplied  a list  of  links 
associated  with  each  non-terminal  node  when  the  graph  was 
created  (Figure  18).  All  that  is  required  for  the  copy  or 
search  operation  to  proceed  is  either  a set  of  boundary  (or 
terminal)  blocks  (nodes)  or  an  integer  value  representing 
the  depth  or  number  of  levels  to  be  spanned. 


Becomes  this; 


BLOCK12 


Figure  18  - Graph  Modification  for  Copy/Search 
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In  conclusion,  copying  (or  searching)  a graph  structure 
would  be  easier,  and  would  take  less  time  to  program  and 
execute,  under  a COMRADE/GIRS  system  with  GIRL  than  under 
the  COMRADE  system. 


V ^ , 
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CONVERSION  OF  A COMRADE  DATA  BASE 
FOR  THE  COMRADE/GIRS  SYSTEM 

Conversion  of  a COMRADE  data  base  to  one  suitable  for  use 
with  GIRS  would  involve  modification  of  the  Block  Type  Def- 
initions (BTD's),  the  Cross  File  Reference  Tables,  and  the 
data  base  itself.  All  pointers  would  have  to  be  eliminated 
from  the  data  base  and  all  pointer  element  names  would  have 
to  be  eliminated  from  the  BTD's.  Under  the  direction  of  the 
DBA,  Cross  File  Reference  Tables  would  have  to  be  unified 
across  a data  base.  Note,  however,  that  present  applications 
programs  would  not  be  affected,  since  COMRADE  could  be  modi- 
fied to  call  the  GIRS  routines  directly  when  a pointer 
operation  was  recognized. 

REMOVAL  OF  POINTERS 

A program  would  have  to  be  written  (under  the  supervision 
of  the  DBA)  to  separate  the  pointers  in  the  COMRADE  data  base 
from  the  data.  Input  to  this  program  would  consist  of  a com- 
plete list  of  all  of  the  data  blocks  in  the  data  base. 

The  DBA  at  this  point,  would  define  a continuant  size, 
keeping  in  mind  the  time  versus  memory  trade-off  between  long 
internal  conflict  lists  and  unused  space  in  the  GIRS  contin- 
uant, as  described  by  Berkowitz.^  The  program  would  then  bring 
in  each  block  and  its  block  type  definition.  A call  to  the 
GIRS  insertion  routine  (INSERT)  would  then  be  generated  with 
the  data  block  name  as  the  source  node,  the  pointer  name  from 
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the  block  type  definition  as  the  link  name,  and  the  value 
or  new  block  name  as  the  sink  node  of  a GIRS  pointer  triple. 

To  partition  the  graph,  the  user  would  have  the  choice  of 
either  allowing  GIRS  to  create  a single  page  (letting  the 
number  of  continuants  grow  as  needed  to  handle  graph  overflow) , 
or  taking  an  active  role  in  designing  the  replacement  (or  new) 
graph.  This  could  be  done  by  designing  a STRATEGY  routine. 

STRATEGY  would  be  called  by  INSERT  and  might  contain  the 
following  instructions:  "If  the  data  block  (source  node)  is  an 
EQUIP  block,  place  the  triple  on  page  two;  if  the  pointer 
(link)  is  a WEIGHT  pointer,  place  the  triple  on  page  three, 
continuant  one;  if  the  data  block  is  DECK,  create  a back 
pointer  to  it  from  its  value;  otherwise,  place  the  triple  on 
the  current  or  most  recently  accessed  page." 

When  the  pointer-removal  procedure  is  complete,  all  of 
the  pointers  will  have  been  removed  from  the  COMRADE  data 
base  and  placed  into  the  GIRS  buffer.  More  relationships  can 
be  added  at  this  point  with  calls  to  PTREXEC,  the  pointer 
executive  routine  which  is  discussed  in  the  next  section.  The 
data  blocks  and  block  type  definitions  would  then  be  compressed 


! and  the  cross  file  reference  table  would  be  updated,  if 
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(1)  He  could  continue  to  call  on  the  CDMS  subroutines  di- 


rectly as  at  present,  although  this  would  be  inefficient, 
since  the  CDMS  routines  must  determine  whether  or  not  to  call 
the  GIRS  routines. 

(2)  He  could  use  GIRL,  as  imbedded  in  FORTRAN,  which 
would  save  both  programmer  and  computer  time,  and  would  also 
allow  for  a better  conceptualization  of  the  data  base 
structure  even  though  the  use  of  GIRL  would  require  a pre- 
processing step*  already  described  in  the  section 

"Adding  a Data-Def inition/Data  Manipulation  Language  to 
COMRADE." 

(3)  He  could  use  PTREXEC,  a pointer  executive  routine 
which  would  have  a calling  sequence  similar  to  the  present 
CDMS  routines.  Use  of  PTREXEC  would  avoid  the  ineffic- 
iencies mentioned  in  the  first  two  methods  but  would  not 
present  a one-to-one  trace  of  the  pointer  operation  to  the 
code . 

PTREXEC  would  also  translate  Hollerith  block  names  into 
their  respective  random  numbers  to  be  used  by  GIRS.  The  first 
input  parameter  to  PTREXEC  would  be  the  operations  code,  an 
integer  which  would  define  the  pointer  operation.  Table  5 
contains  a partial  list  of  possible  pointer  operations. 


* The  GIRL  preprocessor  accepts  a GIRL  program  as  input  and 
creates  a new  all  FORTRAN  applications  program. 
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TABLE  5 - PTREXEC  OPERATION  CODES 


Operation 

Operation 

Number 

Insert  a new  triple  at  the  end  of  a 

list* 

1 

Insert  a new  triple  in  front  of  the  n^ 

value  in  a list 

2 

Delete  array  (multivalue  list) 

3 

Delete  triple 

4 

Retrieve  (first)  value 

5 

Retrieve  n^  value  from  the  top  of 

the  list 

6 

Retrieve  n^  value  from  the  bottom  of 

the  list 

7 

Replace  DATA  value 

8 

* Note  that  if  no  list  exists  a new  triple 

is  created 

The  other  input  parameters  would  be  the  block  name  for  the 
source  node  (IBN),  the  pointer  name  for  the  link  (lEN),  and  the 
value  (DATA)  as  the  sink  node.  ICODE  is  presently  used  for 
both  input  and  output  and  would  continue  as  such.  For  example, 
as  an  input  parameter  to  the  CDMS  routine  CHANGE,  ICODE  is  used 
for  arrays;  under  a COMRADE/GIRS  system  it  would  be  used  for 
multivalue  lists.  As  an  output  parameter,  it  is  an  error  code 
and  its  function  would  not  change. 
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IMPLEMENTATION 


Under  COMRADE,  pointers  are  treated  as  just  another  type  of 
data,  along  with  alphanumeric,  integer,  real,  and  text.  Since 
under  COMRADE/GIRS  there  would  no  longer  be  any  pointer  data 
within  the  data  block,  CDMS  references  to  pointers  would  no 
longer  be  relevant  and  could  be  removed  at  the  leisure  of  the 
COMRADE  managers. 

CDMS  routines  which  deal  specifically  with  pointers  would 
have  to  be  modified,  replaced,  or  eliminated.  The  following 
areas  of  COMRADE  would  be  involved: 

In  the  QUERY  program.  To  handle  a parsed  .OF.  clause, 
subroutine  PNTRCE  (Overlay  (3,0))  would  be  replaced  by  a sub- 
routine (PTRCHSE)  which  would  take  the  output  of  Subroutine 
PARSEP  and  treat  the  first  word  in  the  parsed  list  as  a source 
node  and  the  following  words  in  the  list  as  links  and  translate 
this  list  into  one  call  per  link  or  pointer  to  the  GIRS  re- 
trieval subroutine  FIND.  PTRCHSE  would  then  generate  an  array 
of  hits  or  potential  hits  to  be  ANDed  with  the  output  list  of 
a .WHERE,  clause,  thus  reducing  disk  I/O.  (The  conditional 
elements  involved  in  a query  composed  of  both  .WHERE,  and  .OF. 
clauses  would  then  have  to  be  inverted.)  As  a result,  the 
number  of  hits  per  query  would  become  available. 

Overlay  (3,1),  which  handles  the  data  file  switching  to  ac- 
commodate cross-file  pointer  chasing,  would  no  longer  be  needed. 

In  the  CDMS  Subroutine  Library.  Under  COMRADE,  the  cross 

file  reference  numbers  are  local  to  a particular  file  within  a 


COMRADE  data  base.  This  feature  would  be  modified  so  that 


I > 


there  would  be  a single  Cross  File  Reference  Table  (CFRT), 
since  pointers  would  no  longer  be  oriented  to  particular  data 
files.  Each  file  in  the  data  base  would  have  a unique  number 
associated  with  it.  Therefore,  this  number  must  be  packed  into 
every  sink  node  in  the  pointer  graph.  Data  bases  composed  of 
only  one  file  would  not  be  affected.  The  following  subroutines 
might  be  affected: 

PTR.  PTR  is  a routine  in  the  Bulk  Data  Loader  which 

sets  the  pointer  word  in  main  memory.  It 
would  no  longer  be  needed. 

INPFN.  INPFN  is  a retrieval  routine  which  returns  the 

permanent  file  name  from  the  Cross  File  Refer- 
ence Table.  The  input  to  this  routine  is  a 
cross-file  pointer  value  which  has  been  packed  I 

into  the  block  name.  The  function  of  this  j 

routine  would  not  change;  however,  the  routine  | 

would  not  be  needed  until  the  search  was  I 

1 

j 

complete,  at  which  time  it  would  be  called  once  j 

i 

per  query  and  would  return  a list  of  permanent  | 

file  names  when  handed  a list  of  hits. 

To  prevent  existing  applications  programs  from  being  affected 
by  the  addition  of  GIRS,  CDMS  routines  would  have  to  be  modified  j 

j 

to  recognize  requests  involving  pointer  information.  A pointer  | 

operation  may  be  assumed  if  a search  of  the  proper  Block  Type 
Definition  results  in  failure.  The  CDMS  routine  would  then  have  | 

to  call  the  proper  GIRS  routine  directly.  I 

i 
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Certain  software  would  have  to  be  added  to  COMRADE. 

(1)  The  GIRS  subroutines  would  have  to  be  added  to 
comrade's  subroutine  library. 

(2)  Two  new  permanent  files  would  have  to  be  created; 
one,  the  Interactive  Pointer  Manipulation  Package,  to  handle 
pointer  manipulation  at  the  terminal,  and  the  other,  a Bulk 
Pointer  Data  Program  to  handle  batch  jobs  involving  bulk  data 
description  input.  The  Interactive  Pointer  Manipulation 
Package  would  allow  for  updating,  inserting,  deleting,  and 
retrieving  data  block  relationships  at  the  terminal.  It  would 
consist  of  two  parts.  One  part,  the  program  PTREXEC,  would  be 
a pointer  executive  routine  with  both  long  and  short  tutorials. 
This  program  would  convert  tutorial  responses  directly  into 
calls  to  the  GIRS  subroutines.  A similar  program  is  already  in 
existence.  The  other  part  would  be  a collection  of  subroutines 
created  to  parse  and  handle  such  typical  graph  manipulation 
operations  or  requests  as; 

. Delete  all  references  to  Data  Block  (Node)  x 

. Delete  Node  x and  its  descendants 

. Delete  Node  x and  reconnect  its  ancestor  to  all  of  its 
descendants 

. Add  Node  x to  List  y 

. Retrieve  all  of  the  descendants  to  Node  x 
(Of  course,  some  of  these  operations  would  require  that  the 
graph  be  adequately  constructed  with  back  pointers  and  also  that 
the  pointer  (link)  names  be  available,  in  a stack,  perhaps.) 
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pointer  operations  for  batch  input  would  process  whatever  DDL,  j 

such  as  GIRL,  were  used.  A GIRL  language  preprocessor  has  al-  | 

ready  been  made  available,  which  allows  FORTRAN  statements 
(such  as  calls  to  routines  in  the  CDMS  subroutine  library) 
to  be  interspersed  with  GIRL  statements  thus  making  possible 
the  performance  of  efficient  operations  of  the  form: 

Delete  data  block  x at  the  end  of  the  pointer  search. 

The  proposed  method  of  converting  a COMRADE  data  base  to 
a COMRADE/GIRS  data  base  best  serves  the  interests  of  both 
the  applications  programmer  and  the  DBA.  As  more  needs  are 
defined,  the  implementation  may  be  extended. 
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SUMMARY 


The  advantages  of  removing  the  logical  structure 
(pointers)  from  the  data  blocks  and  collecting  them  into  a 
single  area  are  several: 

. Most  of  the  disk  I/O  presently  needed  for  accessing  and 
modifying  data  block  relationships  can  be  eliminated — and 
thus  response  time  for  a COMRADE  retrieval  reduced — since 
a large  collection  of  pointers  can  be  brought  into  main 
memory  at  one  time. 

. Partitioning  of  pointer  sets  can  be  flexible  (at  the  cost 
of  keeping  a certain  amount  of  space  always  "available"), 
so  that  a programmer  need  no  longer  be  constrained  by 
the  predetermined  data  block  formats  known  as  Block 
Type  Definitions. 

. The  data  base  structure  can  be  conveniently  operated  on 
by  a pointer  manipulation  scheme,  since  pointers  are 
concentrated  in  a single  area. 

. Using  such  a pointer  manipulation  scheme  enables  the 
introduction  of  a powerful  data-def inition/data  manip- 
ulation language  such  as  GIRL  (Graph  Information 
Retrieval  Language)  into  the  system,  with  the  following 
benefits; 

(i)  Programming  and  debugging  time  can  be  reduced  by  vir- 
tue of  the  one-to-one  correspondence  between  the  DDL/ 
DML  code  and  the  pointer  relationships  represented. 


(ii)  Imprecise  queries  can  be  handled,  albeit  at  the 


expense  of  memory  and  disk  space. 

(iii)  The  data  base  administrator  is  provided  with  such 

features  as  (a)  automatic  addition  of  back  pointers, 
and  (b)  automatic  connection  of  the  parents  and  off- 
spring of  a data  block  to  be  removed. 

. The  logical  structure  need  not  be  created  at  the  same 
time  that  the  data  base  is  created. 

. The  recognition  and  reporting  out  of  large  file 
structures  becomes  feasible. 

. Only  finally  qualifying  "hit"  blocks  are  brought  into 
main  memory  when  both  a pointer  search  and  a conditional 
test  are  involved. 

An  effective  scheme  for  manipulating  pointers,  known  as 
GIRS  (Graph  Information  Retrieval  System),  has  already  been 
developed  in-house.  This  system,  written  in  FORTRAN  and 
readily  portable,  allows  a user-defined  "STRATEGY."  Although 
a price  must  be  paid  for  the  gain  in  speed,  flexibility,  and 

t 

i convenience  it  provides,  the  amount  of  extra  memory  and  disk 

I space  involved  is  generally  in  direct  proportion  to  the  degree 

r of  convenience  and  flexibility  to  be  gained. 

I GIRS  offers  a new  tool  for  the  data  base  administrator. 

I The  DBA  will,  of  course,  be  responsible  for  (1)  determining 

j certain  GIRS  parameters  to  optimize  performance,  and  (2) 

I determining  how  best  to  partition  the  relationship  graph. 

I 

i I Fortunately,  existing  applications  programs  need  not  be  con- 


verted,  since  the  pertinent  COMRADE  routines  can  be  modified 
to  call  the  GIRS  routines. 

In  conclusion,  the  speed,  flexibility,  traceability  (in 
the  case  of  GIRL),  and  the  manageability  of  the  proposed 
COMRADE/GIRS  system  are  the  most  compelling  arguments  for 
the  implementation  of  such  a system.  The  advantages  must 
be  weighed  against  the  additional  space  requirements  and  the 
extra  costs  involved. 
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APPENDIX  A 

THE  "PRESIDENTS"  DATA  BASE 

The  "Presidents"  Data  Base®  has  been  designed  by 
Stanley  E.  Willner  of  DTNSRDC  for  tutorial  purposes.^  It  con- 
tains political  and  personal  information  on  the  U.S.  presidents 
and  is  structured  as  illustrated  in  Figure  19. 

LOGICAL  DATA 
STRUCTURE 


The  "Presidents"  Data  Base  is  composed  of  block  types 
(data  block  formats)  PRES,  ELECTION,  CONGRESS,  ADMIN,  and 
STATES,  as  illustrated  by  Figures  20  through  24,  respec- 
tively. There  are  35  data  blocks  of  the  type  PRES,  one  for 
each  president;  45  data  blocks  of  the  type  ELECTION,  one  for 
each  presidential  election  up  to  1964;  53  data  blocks  of  the 
type  ADMIN;  90  of  the  type  CONGRESS;  and  50  of  the  type  STATES 
Altogether  there  are  281  data  blocks,  two  subdirectories, 
and  291  pointers  in  the  entire  data  base.  The  average  data 
block  length  is  23.55  words. 
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BLOCK  TYPE-PRiS 


SUB-BLOCK  1-  PERSONAL 


ELEMENT 

1-  SURNAME 

ALPHA 

INVERTED 

ELEMENT 

2-  FIRSTNAN 

ALPHA 

ELEMENT 

3-  INITIAL 

ALPHA 

ELEMENT 

4-  MONTHB 

ALPHA 

ELEMENT 

5-  OAYB 

INTEGER 

ELEMENT 

6-  YEARS 

INTEGER 

INVERTED 

ELEMENT 

7-  STATES 

ALPHA 

INVERTED 

ELEMENT 

8-  STATEPTR 

POINTER 

ELEMENT 

9-  HEIGHT 

ALPHA 

ELEMENT 

10-  party 

ALPHA 

INVERTED 

ELEMENT 

11-  COLLEGE 

ALPHA 

ELEMENT 

12-  ANCESTRY 

ALPHA 

INVERTED 

ELEMENT 

13-  RELIGION 

ALPHA 

INVERTED 

ELEMENT 

14-  OCCUR 

ALPHA 

ARRAY 

ELEMENT 

15-  NONTHO 

ALPHA 

ELEMENT 

16-  OAYD 

INTEGER 

ELEMENT 

17-  YEARO 

INTEGER 

ELEMENT 

18-  CAUSE 

ALPHA 

REPEAYINS  GROUP  1-  NAME 

ELEMENT  1 
ELEMENT  2 
ELEMENT  3 

REPEATING  GROUP  2-  BIRTH 

ELEMENT  4 
ELEMENT  5 
ELEMENT  6 
ELEMENT  T 

REPEATING  GROUP  3-  DEATH 

ELEMENT  15 

element  16 

ELEMENT  17 

element  18 

SUB-BLOCK  2-  FAMILY 

ELEMENT  1-  FATHER  ALPHA 

ELEMENT  2-  MOTHER  ALPHA 

ELEMENT  3-  RIFE  ALPHA 

ELEMENT  4-  NONTHN  ALPHA 

ELEMENT  5-  OAYM  INTEGER 

ELEMENT  6-  YEARM  INTEGER 

ELEMENT  7-  CHILDREN  INTEGER 

REPEATING  GROUP  1-  MARRIAGE 

ELEMENT  3 
ELEMENT  4 
ELEMENT  5 
ELEMENT  6 
ELEMENT  7 

SUB-BLOCK  3-  HISTORY 

ELEMENT  1-  ELECTION  POINTER  ARRAY 

ELEMENT  2-  AOMIN  POINTER  ARRAY 

ELEMENT  3-  CONGRESS  POINTER  ARRAY 


Figure  20  - Block  Type  PRES 


I 
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BtOCK  TYPE 

-ELECTION 

SUB-BLOCK 

1-  suai 

ELEMENT 

1- 

YEAR 

INTEGER 

INVERTED 

ELEMENT 

2- 

NlNNER 

ALPHA 

INVERTED 

ELENENT 

J- 

PRESPTR 

POINTER 

ELEMENT 

<*- 

MPARTY 

ALPHA 

INVERTED 

ELENENT 

5- 

VOTES 

INTEGER 

ELENENT 

6- 

OPPNANE 

ALPHA 

ELENENT 

T- 

OPPPARTY 

ALPHA 

ELEMENT 

8- 

OPPWOTES 

INTEGER 

REPEBTINS 

GROUP  1-  OPPONENT 

ELEMENT  6 

ELENENT  7 

ELENENT  8 

Figure 

21  - Block  Type 

ELECTION 

BLOCK  TYPE-STATES 

SUB-BLOCK 

1-  SUBl 

ELENENT 

1- 

STATE 

ALPHA 

INVERTED 

ELENENT 

2- 

TEARA 

INTEGER 

INVERTED 

ELEMENT 

l- 

capital 

ALPHA 

ELEMENT 

L- 

AREA 

INTEGER 

INVERTED 

ELENENT 

5- 

AREARANK 

INTEGER 

INVERTED 

ELEMENT 

o- 

POPUL 

INTEGER 

INVERTED 

ELENENT 

7- 

PO PRANK 

INTEGER 

INVERTED 

ELEMENT 

8- 

ELECVOTE 

INTEGER 

ELENENT 

9- 

CITY 

ALPHA 

INVERTED 

ELEMENT 

18- 

CITYPOP 

integer 

INVERTED 

repeating 

GROJP  1-  CITIES 

ELENENT  9 

ELENENT  19 

Figure  22  - Block  Type  STATES 
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BLOCK  IT»E-»0MIN 


SUB-BLOCK  1-  SUBl 


ELEMENT 

1-  MONTMI 

ALPHA 

ELEMENT 

2-  OAYI 

INTEGER 

element 

3-  TEARI 

INTEGER 

INVERTEO 

ELEMENT 

4-  VPFIRNAM 

ALPHA 

ELEMENT 

5-  VPSURMAM 

alpha 

INVERTED 

ELEMENT 

6-  PRESPTR 

POINTER 

ELEMENT 

T-  SECSTATE 

ALPHA 

ELEMENT 

S-  SECNAR 

ALPHA 

ELEMENT 

9-  SECTRES 

ALPHA 

ELEMENT 

10-  ATTYGEN 

ALPHA 

ELEMENT 

11-  NEMSTATE 

ALPHA 

INVERTEO 

ELEMENT 

12-  STATEPTR 

POINTER 

REPEATINC  SROJP 

repeating  croup 

REPEATING  CROUP 

REPEATING  GROUP 


1-  INAUG 
ELEMENT  1 

jELENEMT  ^ 
ELEMENT  3 

2-  TICEPRES 
ELEMENT  L 
ELEMENT  5 

3-  CABINET 
ELEMENT  T 
ELEMENT  S 
ELEMENT  9 
ELEMENT  10 

R-  STATES 

ELEMENT  11 
ELEMENT  12 


Figure  23  - Block  Type  ADMIN 


BLOCK  TTPE-CONGRESS 


SUB-BLOCK  I-  SUBl 


ELEMENT 

ELEMENT 

ELEMENT 

element 

ELEMENT 


1-  NUMBER  INTEGER 

2-  SPARTT  ALPHA 

3-  SENATORS  INTEGER 

4-  HPARTT  ALPHA 

5-  REPS  INTEGER 


INVERTED 


REPEATING  GROUP  1-  SENATE 

ELEMENT  2 
ELEMENT  3 


REPEATING  GROUP  2-  MOUSE 
ELEMENT 
ELEMENT 


4 

5 


Figure  24  - Block  Type  CONGRESS 
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APPENDIX  B 

SEARCH  PROCEDURE  WRITTEN  IN  GIRL/FORTRAN  FOR  INDIRECT, 
MEMORY-RELATED  QUERIES 

The  following  procedure  taken  from  the  report  by  Berkowitz^ 
indicates  code  typical  of  search  procedures. 


IDFER:  B of  A (Ivon  that  A Is  of  typo  C.  If  (C>0)  BZTOUl 

c *00  IISXA  HOLDS  DOWN  LINKS  OF  C 

C 2 LISTA  (HOLDS  C 'TDIP,  REFEK  TOP) 

JTQIP-0 
3 J-O 

0 4 TBtt  + DOWN/6  .'J-J+176-B/ 'NEXT  5/7 

G 5 LISTA(HOLDS  NEXT,  REFER  'JTBtP'//4) 

G 6 LISTA{+HOLDS.’JTniP“JTBff+l'  /I5/'TBO>3) 

C ***  COMPILE  STRING  OF  LINKS  FROM  C DOWN  TO  B 

G 7 LISTA  STRING(B,TEMP) 

G 8 LISTA(-f«EFER.JTaiP'JTEMP-T0P//9, -WOLDS. JTEHP'TBff, STRING 

TEMP//8) 

C ***  GENERATE  LISTS -.TREE  OF  NODES  BASED  ON  LINE  STRING 

9 J-O 

G A'NODE 

G 10  LISTA+STRINC.'J-J-1"TBMP-B//13 

K-O 

G 11  NODE+TEMP.'K-K-t-l'/lX'NEXT 

G LISIB/STRING  NEXT, REFER  'J'//ll) 

G 12  LISTB(-t-STRING/16(.l’NODE,-.l,-WEFER(.l’J,-.l//10))) 

C ***  OUTPOT  NODES  LINKED  BY  B 

13  JJ-O 

G 14  N0DBtB.'JJ-JJ-t-l'/12'0UT 

PRINT(OUT) 

GO  TO  14 

15  PRINT('FAIL') 

16  RETURN 
END 

THIS  PAGE  IS  BEST  QUALITY  I^RACTICABLE 
BBOM  OOiPX  FURNISHED  TO  MiQ 
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APPENDIX  C 

TWO  SUBROUTINES,  AS  CODED  IN  FORTRAN  FOR  CDMS  AND  GIRS, 

AND  AS  CODED  IN  GIRL 

Two  subroutines,  DELEQ  and  DLEQPT,  have  been  selected 
from  the  DTNSRDC  Ship  Design  File  to  illustrate  the  coding 
differences  for  COMRADE  and  for  COMRADE/GIRS . DELEQ  is  used 
to  delete  a particular  data  block  and  all  of  its  descendants 
from  the  Ship  Design  File.  DLEQPT  is  used  to  disconnect  any 
pointers  pointing  to  the  deleted  blocks  and  to  reconnect  them 
to  the  parent  of  the  deleted  block. 

DELEQ  operates  on  a simple  "preorder"  traversal  technique 
for  both  CDMS  and  GIRL  versions,  whereas  DLEQPT  uses  a much 
more  involved  algorithm  whicn  will  not  be  considered  here. 

The  sequence  of  events  for  the  GIRL  version  of  DLEQPT  is 
similar  to  that  used  in  the  CDMS  version. 

The  GIRS  version  of  both  routines  has  been  produced  by 
the  GIRL  preprocessor.  Handwritten  GIRS  code  would  be  a bit 
more  efficient  and  would  also  take  less  space  in  main  memory. 

Table  6 compares  the  number  of  statements  needed  to  accomplish 
the  task  under  CDMS  and  under  GIRL. 


I 
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TABLE  6 - RATIO  OF  GIRL  STATEMENTS  TO  COMRADE  STATEMENTS 


Subroutine 

Name 

Number  of  Statements  Needed 

COMRADE 

GIRL 

Ratio  of  GIRL 
Statements  to 
COMRADE  Statements 

DELEQ 

107 

42 

.3925... 

DLEQPT 

160 

71 

.44375 

Total 

267 

113 

.4232. . . 

One  final  comment;  After  becoming  familiar  with  the  two 
routines,  the  author  was  able  to  write  the  GIRL  code  for  DELEQ 
in  approximately  half  a day,  and  that  for  DLEQPT  in  approxi- 
mately one  and  a half  days. 

CDMS,  GIRL,  and  GIRS  code  follows: 
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AS  CODED  IN  FORTRAN  FOR  CDMS 


subroutine  oeleq 


7h/7h  OPTxt  ROUNOx*/  TRACE 


FTN  4.5«R<i06 


1 SUBROUTINE  DELEaCEQINI 

C 

L-THIS  ROUTINE  DcLETlS  AN  EQ  BLOCKIEQINI  ANO  ALL  SU8BLOCKS  FRCH  THE 
C-SHIP  OESIGN  fill,  ANO  DELETES  ALL  POINTERS  TO  THOSE  BLOCKS. 

5 C 

COHHCN/UNITS/LFNiICONN 

OIMENSION  PI2)  >IPV(2I  /STACKdSOt.OATAIlOO)  flPIlOOt 
BATA  P/2rtAR,2HSH/,NPTRS/2/,IPV/l,2/ 

l-initialize  variables 

10  ISUH  X 0 

ISBN  • 4HPTRS 
FNCTl  X SLNOTONE 
SEVSIX  X 762626767176767626768 
ISTACK  X 0 
IS  PEQ  X zheQ 

C-SET  EQCUR  TO  EQIN 
EQCUR  X £QIN 
L-PLACE  EQCUR  ON  STALK 
10  iSTACK  X ISTACK  • 1 

20  STACKdSTACKl  x EOCUR 

ISUH  X a 

C-FETCH  THE  POINTERS  FROM  EQLUR  TO  EACH  OF  THE  POSSIBLE  P BLOCKS,  SEE 
C-HHICH  IS  equal  TC  NOTONE,  ANO  SET  THE  PROPER  IPlISTACKi  TO  THE  SUN  OF 
C>THE  PROPlR  IPV(S. 

25  IRGR  X o 

00  30  Ix1,NPTRS 
EN  X P(li 
LENGTH  X 1 

CALL  CCHRLORC  SLFETCH , lERR, EQCUR, ISBN , 0 , IRGR, EN ,EOUT , LENGTH) 

30  IFtlERR.NE.O)  lAU.  ERR<5HFETCH,IERR) 

C-SET  IP  SUNNING  COUNTER  I SUN 

IFCEOUT.EO.PNOTl)  ISURxISUHxIPVd) 

30  CONTINUE 

c-ouT  OF  loop-set  IPCISTACKI 
35  IP(iSTALK)  X ISUH 

L-OOES  EQCUR  HAVE  ANV  SU6-EO(ST  FETCH  THE  OONN  POINTERS  OF  EOCUR 
40  IRGR  X 0 

LENGTH  X 100 

CALL  CONRLORT SLFETCH, lERR, EQCUR, ISBN, 5HOPTRS, IRGR, 2HEQ, DATA, LENGTH 
40  1* 

00  45  JKxl, length 
IFtOATAIJKI.NE. SEVSIX)  GO  TO  46 

45  CONTINUE 

IF(IERR.Nl.O)  CALL  ERRtSHFcTCH ,iERRI 
45  C-ALL  SbVEN  SIXES  INDICATE  NO  SUB-EQS 

GO  TO  50 

C-EQCUR  OOES  HAVE  SUBEQTS.  SET  EQCUR  TO  FIRST  SUB-EQ,  THE  GO  BACK  ANC 
C-PLACE  IT  ON  STACK  ANO  SET  IP 

46  EQLUR  X OATAIJK) 

50  GO  TO  10 

C-EQCUR  OOES  NOT  HAVE  SUB-EQTS.  HON  NANV  BLOCKS  ARE  IN  STACK. 

50  IFdSTACK.EQ.  1)  GO  TO  110 

C-SET  IPOIF 

IPOIF  X IPIISTACK-I) -IPCISTALK) 

55  C-FOLLONING  loop  DELETES  ALL  BACK  POINTERS  TO  EQCUR 

00  BO  1x1,NPTRS 
C-SET  isua 

ISUB  X 2>x|mpirs-I) 

1FIIP01F.lt. ISLBi  CO  TO  00 
60  C-IPCIF  IS  GE  ISUB.  FIRST  SET  PTR 

PTR  X F(NPTRS-1»1) 

C-FETCh  value  of  PTR  OF  EQCUR  AND  PLACE  IT  IN  PTCUR 
IRGR  X 0 
LENGTH  X 1 

65  CALL  CCHRL0RISLFETCH,1ERR,EQCUR, ISBN, 0, IRGR, PTR, PTCUR, LENGTH) 

IFIIENR.NE.O)  CALL  ERH(5HFETCH,IERR) 
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C'NOM  MUST  DELETE  EQCUR  FRCH  THE  EQ  FTRS  OF  FTCUR.  FIRST  MUST  FIND 
L-MNICH  OCCUfREMCE  OF  EO/FICUR  IS  EOUaL  TO  EQCUR.  FETCH  ALL  EQ 
C'OCCURRENCES 
IRCR  - 0 
LEKCTH  a .110 
IFtRTR.NE.ZHSM)  60  TO  55 
EQRG  ■ 0H1TENFTR6 
lOFTR  a 7HITEMPTR 
GO  TO  SO 

55  EQRG  a lhEGRG 
lOFTR  a zhEQ  , « 

50  CALL  CCMRLOM5LFETGH,lERRfPTCUR>lSaNfEORG,lRGR»IOPTR«OATA.LEM6THl 
IFlIERR.NL.It  call  EKR(5HFLTCH,IERR) 

C-LOOP  TO  SC.E  HHICH  CCCUAHENCE  IS  EQCUR  AND  THEN  DELETE  IT. 

DO  60  Kal, length 
IFCEOLUR.NE.OATAIKI)  GO  TO  60 
L-EOCUR  IS  THE  KTH  OCCURRENCE  IN  EQ/PTCUR.  DELETE  IT. 

CALL  C CHRLORt 6L0£LcTE , IE  RR |PTC URt ISON, EQRG.K , 0 > 

IFIIERR.NE.I)  CALL  ERR(6H0ELETE,1ERRI 
60  TO  70 
60  CONTINUE 

C*RCSET  IPOIF-CONTINUE  LOOPING  IN  MAJOR  LOOP 
70  IPOIF  a IPOlF-ISUe 
60  CONTINUE 

C'OElETE  OLOCK  EQCUR  FROM  THE  SHIP  DESIGN  FILE 
CALL  CCNRLaR(6L0ELEia,lERR,EQCUR» 

C-THIS  ROUTINE  MILL  BUILO  SACK  POINTERS  FROM  THAT  OTHER  BLOCK  TO  EACH 
IF(IERR.NE.I)  CALL  c ARI6H0ELETB,IERR) 

C-SET  EQLST  to  EQCUR 
EQLST  a EQCUR 

C'SET  EQCUR  TO  NEXT  SLOCK  ON  STACK 
ISTACK  a ISTACK-1 
EQCUR  a STACKdSTACKI 
IRGR  a 0 
LENGTH  a 100 

CALL  CCMRLORISlFETCH, TERR, EQCUR, ISBN, 5H0PTRS,1RGR,ZHE0,DATA,LEN6TH 
II 

C-DELETE  EQLST  FROM  EO/EOCURIOONN  FOINTERI  FIRST  FETCH  ALL  BONN 
C-POINTERS  EG/cQCUR 

IFCIERR.NE.OI  CALL  ERR(5HFETCH,IERR1 
C-OO  LOOP  TO  FIND  EQLST  ANu  DELETE  IT. 

DO  90  Kal, LENGTH 
IFIEOLST.HE.OATACKII  60  TO  90 
C-OELETE  IT  AS  IS  KTH  OCCURRENCE 

CALL  CONRLOR(6lOELET£,IEKR, EQCUR, ISBN, 5HDPTRS,K, 01 
IFdERR.NE.OI  CALL  EARIOHOELETE ,IERRI 
GO  TO  100 
90  CONTINUE 

C-START  PROCESS  AGAIN  HITH  NEH  EQCUR 
ISO  60  TO  60 
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C'UNLV  1 BLOCK  LEFT  QN  STACK.  FIRST  SET  EQFM  TO  THE  FMENT  OF  EOIN 
110  IRCR  ■ 1 
LEMCTH  > 1 

12B  CALL  CCHRL0R($LFETCH,lERRtE«IN,ISaN>5HaPTRSfIRCR.2HPR,EQPAR,LEL6TH 

1) 

IFlIERR.Nt.OI  call  ERACSHFETCH.IERRI 
C-FINO  OUT  IF  EQFAk  IS  INObEO  AN  EO  BLOCK.  GET  FIRST  Z CHARACTERS 
C>OF  EQPAR  MITH  HOVE  ANO  TEST  ON  IT. 

IZS  ARRAYl  > lOH 

call  C OHRLOKI ALHOVE  t ARRAYl , 1 .EOPAR. 1 • Z tlERRI 
IFlILRR.Nfe.O)  call  bRROAHNOVE,  lERRI 
C-CHECK  FIRST  Z CHARACTERS  AGAINST  EO 
IF (ARRAYl. HE.PEQI  GO  TO  lAO 

130  C'EOPAR  IS  AM  LO  BLOCK.  LOOP  TO  DELETE  BACK  POINTERS  TO  IT. 

00  IZO  K^lfNPTRS 

C«SET  PTR  TO  P(Kt  TO  GET  TYPE  OF  POINTER. 

PTR  > P(K> 

C'PlACE  value  of  PTR  OF  EQCUR  IN  VARIABLE  PTCUR 
13S  IR6R  « I 

LEMCTH  s 1 

call  COHRLORISLFETCHiIERRtEQCURflSBNiOtlRGRtPTRtPTCUR.LCNGTH) 
IFdERR.NE.OI  CALL  ERRCSHFETCH .lERRt 

C'CALL  OLEOPT  TO  OELcTE  TO  ANO  FROM  FTRS  ANO  HAINTAIN  HIERARCHY  OF  PTRS 
ICO  CALL  OLEOPT (EQCURiPTRt 

C-ENO  OF  LOOP 
IZO  CONTINUE 

C'OELETE  EOCUR  FRON  EO(S  OF  EOPAK.  FIRST  FETCH  ALL  EO(S  OF  EOPAR 
IKCR  > 0 

1C5  LENGTH  « 100 

CALL  COHRLOR(5LFETCH>lERR|EQPAR>lSBN,5HOPTRStIRGRiZHEQtOATA,LENGTH 
II 

IFdbRR.NE.ei  CALL  ERRYSHFETCH.IERRI 
C-00  LOUP  TO  FIND  EOCUR  ANO  CELETE  IT. 

150  00  130  Ksl.LENuTH 

IF(tQCUR.NE.OATA(KI>  GO  TO  130 
C-EOCUR  IS  KTH  OCCURRENCE  - DELETE  IT 

CALL  CCHRLORC 6L0ELETE t IERR tEQPARi ISBN > 5H0PTRS, K, 01 
IFdERR.NE.OI  CALL  ERR(6H0ELETE.IERRI 
155  60  TO  ICO 

130  CONTINUE 

C-OElETE  EOCUR  FRON  SHIP  OESIGN  FILE 
ICO  call  CCHRL0R(6L0ELEIB,IERRfEQCURI 

IFdERR.NE.OI  CALL  £RR(6N0ELETB,IERRI 
160  C-FINISHtO-RETURN 

RETURN 
ENC 

STATISTICS 

PROGRAM  LENGTH  ICICB  TOO 

CM  LABELED  CONHON  LENGTH  ZB  Z 


93 


«! 


SUBROUTINE  OLCORT 


II 


IS 


21 


2$ 


31 


3S 


*$ 


$1 


55 


61 


SUBROUTINE  OLEQPT(EaiN,PTRl 


C'CIIEN  AN  cO  BLOCK lEQIN) 
C'THIS  ROUTINE! 


ANO  A POINTER  TTPE(PTR)  TO  ANOTHER  BLOCK, 


C- 

C- 

C- 

C« 

c- 

c- 

c 


1-  CELETES  THE  POINTER  TO  THE  OTHER  BLOCK 

2-  OELETES  THE  SACK  POINTER  FRON  THE  OTHER  BLOCK  TO  THE  EO 
BLOCK 

3-  UPDATES  POINTERS  FRON  ANO  BACK  POINTERS  TO  HI6HER  EQ 
SLOCKS  AS  NECESSARY  TO  HAINTAIN  THE  HIERARCHICAL  SEQUENCE 
OF  CNOTONECS,  REAL  POINTERS,  ANO  t LINBOCS. 


COMNON/UNITS/LFN, ICONS 
OIHENSION  OATA(llOI,OAT(iaOI,ARRATC2l 
C-INITIALIZE  VARIABLES 
PEQ  > lOHEQ 
ISSN  > 4HPTRS 
PLINSO  « 6HLINB0 
FNOTl  > SLNOTCNE 
IFIPIR.NE.2HSNI  GO  TO  J 
EQRG  > BHITEHPTRG 
ELEN  « 7HITEHPTR 
GO  TO  M 

3 EQRG  > AHEQRG 
ELEH  > 2HEQ 
6 CONTINUE 
ICOOE  > D 
lERR  > I 

C-FETCH  THE  PTR  OF  EQIN  ANO  PLACE  ITS  VALUE  IN  PTRINC 
IRGR  < 0 

length  > t 

CALL  CCNRLORt 5LFETCH,IERR, EQIN, ISBN, 0,IRGR,PTR,PTRIN,LEN67HI 
IF(IERK.NE.ai  CALL  ERRiSHFETCH ,IERRI 
C-SET  PTCUR  ANO  EOCUR  TO  EQIN 
AKRATl  > PTR 

C ALL  C CNRLORl 6LNOVE , ARRA Y1 , 3,PLIN80, 1 , 5, lEKRt 
IFlIcRN.NE.OI  CALL  ERR(6HN0VC,IERR> 

C-IS  PTRIN  A LINBO  BLOCK 

INACH  < ICAN(PTRIN,1,ARRAY1,1,TI 
IFtINACh.NE.ll  GO  TO  5 

C-PTRIN  IS  A LINBO  BLOCK.  BEFORE  RETURNING  DELETE  EOCUR  AS  AN  EO/PTR 
L-OF  PTRIN.  first,  FETCH  AU  EQ/PTRS  OF  PTRIN 
length  « 100 
IRGR  > 0 

CALL  CONRLOR(5LFETCH,IERR,PTRII>,IS8N,tORG,IRGR,ELEN,OATA,LCN6THI 
IF(IERR.NE.O)  CALL  ERR(5HFLTCH,IERRI 
00  2 I>1, LENGTH 
IFIEQIN.NE.OATAII)>  GO  TO  2 
C-OELETE  EOCUR  FRON  EO/PTRIN 

CALL  CCHRLORTGLOELETE , IE RR ,PTR IN, ISBN , EQRC,I , B I 
IFIIERR.NE.OI  CALL  ERR(6H0ELETE, lERRI 
GO  TO  ISO 
2 CONTINUE 
GO  TO  too 

C-SET  PTCUR  ANO  EOCUR 
5 PTCUR  > PTRIN 
EOCUR  a eOIN 

C-OELETE  PTR/POINTER  OF  EOCUR  TO  PTCUR 
10  IRGR  > 0 

CALL  CCNRLOR(6LOELETE,IERR,EQCUR,  ISBN,a,IRCR,PTR* 

IFIIERR.NE.OI  CALL  ERRI6H0ELETE,1ERRI 
C-SET  EOLST  TO  EOCUR 
cQLST  > EOCUR 
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C-6ET  NEM  EQCUA  BY  FETCHING  OORENT  OF  CUMtEHT  EQCUR  6N0  PL6CIN6  ITS 
C-V6LUE  IN  EQCUR 
XRGR  > 1 
LENGTH  3 1 

CALL  L(MHLaH(5LFETCHtI£RR«EaCURfIS6N,5HaprRS«lRGR»2HPfi,£SH0T(LENCT 
IHI 

IFlUhH.NE.OI  CALL  ERR(5HFETCH,XE«ll 
EQCUR  > ESHOT 

L'HHAT  IS  THE  BLOCKTVPE  OF  EOCUR 
ARRATl  3 lOH 

CALL  CCHRL0RIGLH0NE,ARRAVltl>E0CURilt2ilEimi 
IFdERR.NE.OI  CALL  ERRUHHOVE.  lERRI 
C-EQCUR  IS  NCT  AN  EQ  BLOCK  TVPE-DONE-RETURN 
IFtARRAYl.NE.PEOI  CO  TO  ISO 
C-EQCUR  IS  AN  EQ  SLOCK  TYPE.  SET  PTLST  TO  PTCUR 
PTLSI  3 PTCUR 

C-SET  A KEM  PTCUR  BY  PLACING  IN  IT  THE  VALUE  OF  PTR  OF  EQCUR 
LENGTH  3 1 
IRGR  3 0 

CALL  CCHRLORISLFETCH, lERR, EQCUR. ISBN.OiIRGRfPTRfPTCURf LENGTH) 
IF(IERR.NE.O)  CALL  ERR<5HFETCH .lERR) 

IFIPTCUR.NE.PTRIN)  GO  TO  SO 

C-THE  value  of  PTCUR  IS  PTRIN.  GET  THE  NUH8ER  OF  OCNN  POINTeRSIEQCS)  OF 
C-BLCCK  EQCUR. 

IKGK  3 0 
LENGTH  3 too 

CALL  CCNRLOR15LFETCH.IERR.CQCUR«ISBN,5HOPTRS. IRGR, 2HEQ. DATA .LENGTH 
1) 

IFdERR.NE.O)  lALL  ERRtSHFETCH .lERR) 

C-LENGTH  is  1,  SO  GO  BACK  ,ScT  EOCUR .ETC.,  ANO  GET  NEXT  ONE. 

IFCLENGTH.EQ.ll  GU  TO  10 
C-LENGTH  GT  1.  OONE—REIURN 

IFlLENGTH.GT.l)  CO  TO  ISO 
C-LENGTH  IS  LT  1-- ERROR- -STOP 
HR1TE(ICUNN,20> 

2Q  FORNATdH  , 30HERROR-EQ<S  OF  EQCUR  HUST  EXIT  1 
CALL  COHRLDRCALFLFN. IERR.lFN) 

IFdERR.NE.O)  CALL  ERRMHFLFk,  lERR) 

STOP 

C-THE  VALUE  OF  PTRIN  IS  NOTCNE.  SET  IOC  TO  ZERO 
SO  100  3 0 

G-IS  PTLST  ECUAL  TO  NOTONE 

IF  (PTLST. EQ.PNOTl)  GO  TO  SO 

C-PTLST  IS  NCT  NOTONE.  DELETE  EQLST  FROH  EQ  PTRS  OF  PTLST.  FIRST  NUST 
C-FETCH  ALL  EQ(S  FRON  PTLST 
LENGTH  3 ISO 
IRGR  3 0 

CALL  CCNKL0R(5LFETCH, lERR, PTLST .ISBN, EQRG.IRGR.ELEN.OATA, LENGTH) 
IFdcRR.NE.SI  GO  TO  6S 

C-PTLAT  COES  NOT  HAVE  ANY  £0  POINTERS  OR  EQLST  IS  NOT  AMONG  THOSE  THAT 
C-ARE  THERE.  ERROR— ABORT 
AO  NR1TE(ICCNM,5  0) 

50  FORNATdH  .SSHEOLST  NAS  NOT  THERE  TO  OELETE-ABORT  ) 

CALL  CCNRL0K<ALFLFN,1ERR,LFN) 

IFdERR.NE.O)  CALL  ERRCAHFLFN.IERRO 
STOP 

C-NON  TRV  TO  DELETE  EQLST 

60  IFdERR.NE.O)  CALL  ERR(5HFETCH .lERR) 

00  70  l3l, length 
IF(EQLST.NE.OATAd))  GO  TO  70 

CALL  CO«RLDR(6LOELETE.IERR.PTLST.ISBN,EORG.I.O> 

IFdERR.NE.O)  CALL  E£R(6H0ELETE.1ERRI 
GO  TO  SO 
70  CONTINUE 
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C-E(U.ST  NOT  AHOMC  EQCS  OF  EOCUR.  NEEO  TO  KNON  HON  HANV  THERE  ARETLENT 
aO  LEN  > 100 
IRGR  > 0 

130  CALL  CCHRLURI5LFcTCH,l£RR,EaCURtlSaNtSH0PTRS>lRCRiZHEat0ATA,LENI 

IFCIERK.NE.OI  CALL  ERR  (SHF  ETCH  •TERRI 
IFILEN.NE.ll  GO  TO  120 

C-LcN  IS  ONE.  MUST  DELETE  ECLST  FROM  EOTS  OF  PICUR 
IRGR  = 0 

135  length  It  100 

CALL  CCHRLOk(5LFcTCH,lERR«PTCUR«ISBNtEORCflRGR,ELEH,OATAtLENGTHI 
IF(IERR.HE.3I  GO  TO  100 

C-PTCUR  COES  NOT  HAVE  ANT  EO  POINTERS  OR  EOLST  IS  NOT  AHON6  THOSE 
C-EO(S  THAT  GO  AX 1ST.  ERROR-ABORT 
lAO  so  CO  TO  40 

C-NON  TRY  TO  DELETE  EOLST 

100  IFdERk.NE.OI  CALL  ERR(SHFETCH,1ERR> 

00  110  I«l, LENGTH 
IF(EOLST.NE.OATA(ll>  GO  TO  110 

145  call  CCHHLOR(6LOELETE,IERRtPTCURtlSBNfEQRG«IiO> 

IFdCRR.NE.O)  CALL  ERR(6KIELETE|IERR» 

GO  TO  IFO  * 

110  CONTINUE 

C-EOLST  NOT  AHONG  EOCS  OF  PTCUR— ABORT 
150  GO  TO  so 

L-LLN  IS  GREATaR  THAN  ONE  NON  HAVE  LOOP  TO  SEE  ABOUT  TJE  PTR  OF  EACH 

C-SUBaQ  OF  EOCUR 
120  00  140  IxlfLEN 

C-SEE  if  the  ITH  SUBEO  is  EOLST.  IF  IT  IS  CONTINUE 
155  IF(bATAd)  .EQ.EOlSTI  GO  TO  140 

C-CHECK  CN  100 

IFdOU.NE.O)  GO  TO  130 

C-IOC  IS  ZERC.  SET  IT  TO  ONE  ANO  SET  SANE  TO  PTR  OF  OATACl) 

100  < 1 

160  LENGTH  > 1 

BN  > OATAd) 

IRGR  = 0 

CALL  CCHRLOR(5LFATCHfI£RR,BNfISBNtOtIRGRfPTR,SANEfLENGTHt 
IFdERA.NE.O)  CALL  ERRISHFETCH  tIERR) 

165  GO  TO  140 

C-lUC  NAS  NOT  ZERO.  SET  PTRSUB  TO  PTR  OF  OATAdI 

130  aENGTH  a 1 

BN  A OATAdI 
IRGR  A 0 

IFO  CALL  CCHRLORI5LF£TCH,IERRfaNflSBN»S»lRGRfPTR,PTRSUB>LENGTHI 

IFdARR.NE.OI  CALL  ERR(SHFETCH«IERRI 
C-IF  PTRSUB  IS  NOT  EQUAL  TO  SANE  • DONE— RETURN 
IFiPTRSUB.NE.SAHEI  GO  TO  100 
C-ENO  OF  LOOP 

125  140  CONTINUE 

C-IF  SAHa  is  NOTONE,  OONE--RETURN 
IF(SAHE.EQ.PN0T1I  go  to  100 
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C'SAMC  IS  NOT  NOroNC.  MUST  OELETC  EO  OF  SOME  NOINTEMS  MOM  »U  EQCS 
C.-UNOER  POkENTtEQCUR).  FIRST,  HOVE  AIL  EOfS  OF  EOCUR  FROM  OiOVE  M 
C-OROAV  GOTO.  NEXT,  HUST  FETCH  AEL  EQ  PTRS  OF  SANE. 

1EN6TH  > ISO 

IRSR  > 0 

CALL  CONRLORI5LFETCH,IERR,SANE,ISBN,EaR6,INOR,ELEN,OAT,LEHCrHI 
IFIIERR.NE.31  GO  TO  150 
C'SAHE  HAS  NO  EO  PTRS,  SO  HAS  HO  SUOEO  PTRS 
GO  TO  170 

C-NOH  60  through  PROCESS  OF  DELETING  FROM  SANE  ALL  EO  PTRS  HHICH  ARE 
C-SUOEOCS  OF  EOCUR 
ISO  00  160  K>1,LEN 

00  160  J>1, LENGTH 

IF(OATA(K).NE.UAT(J>>  GO  TO  160 

CALL  C0HRLDRI6L0ELET£,lERR,SAHE,ISaN,EaR6,J,9« 

IFI1ERA.NE.0I  CALL  ERR(6H0ELETE,lENRi 
160  CONTINUE 

C-AOO  EOCUR  AS  AN  EO  POINTER  OF  SANE 
170  IFIPTR.NE.2HSHI  60  TO  175 
ARRATIll  « THITENPTR 
GO  TO  170 

175  ARRAVTII  « 2HEO 
170  ARRAT(2I  > EOCUR 
IRGR  > 0 

CALL  CCHRL0R(6LA000, lERRA, SANE, ISaN,E0H6, IRGR, ARRAT, 21 
IFdEKRA.NE.OI  CALL  ERRI6HAOOO ,IERRAt 
C-SET  PTR  OF  EOCUR  TO  SANE 

CALL  CaNRLOK<6LCHAN6E,ICOOE,EOCUR,IS8N,PTR,SANE> 

IFIICOOE.NE.S)  CALL  ERRC6HCHANGE,IC00E) 

C-SET  EOLST  TO  EOCUR 
EQLST  > EOCUR 

t-SET  VALUE  OF  EOCUR  TO  THE  PARENT  NAME  OF  THE  PRESENT  EOCUR 
LENGTH  > 1 
IRGR  « 1 

CALL  COHRLaR(5LFCTCH,IERR,EOCUR,IS8N,5H«PTRS,IRGR,2HPR,CSHOT,LEN6T 
IHl 

IFIIERR.NE.OI  call  ERR(5irETCH,IERRI 
£aCUIi  > ESH07 

C-FINO  IF  BLOCK  TYPE  OF  EOCUR  IS  EO  OR  NOT 
ARRAVl  « lOH 

CALL  CCNRL0R16LN0VE, ARRAVl, l,EOCUR,l, 2 tlERRI 
IFtURR.NE.SI  «.ALL  ERRC6HH0V£,1ERR) 

C-EOCUR  IS  NOT  AN  EO  BLOCK-OONE— RETURN 
IFIARRAVl.NE.PEQt  GO  TO  ISO 
C-EOCUR  IS  AN  EO  BLOCK.  SET  PTCUR  TO  PTR  OF  EOCUR 
LENGTH  > 1 
IRGR  « 0 

CALL  COMRLJR(5LPETCH,IERR,EOCUR,IS8N,0 (IRGR, PTR, PTCUR, LENGTH) 
IFIIERR.NE.O)  CALL  ERR (SHF ETCH tlERR) 

C-GO  TO  NHENe  getting  THc  SUBEOCS  OF  EOCUR  ANO  RESUNE  PROCESS  FROH 
C-THERE. 

GO  TO  SO 

C-ENO  OF  ROUTINE 
ISO  RETURN 
ENO 
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SUBROUTINE  OELEQIEQtNI 

THIS  ROUTINE  DELETES  AN  EO  SLOCKIEQINI  AND  ALL  SUBSLOCKS  FROM  THE 
SHIP  DESIGN  FILE.  AND  DELETES  ALL  PCINTERS  TO  THOSE  BLOCKS. 

INTEGER  EOIN.HOLNAH.PEO.PTR.ARRAYI.EQCUR.PTCUR.P.EQPAR.PARENT. 

» STACK 

CONHON  /NAHE/  LVNANE 

CONHON  /NODES/  PNOTl.EQ.AR. SN. ITEHPTR.PR 
OIHENSION  PIZt.STACKIlOOl 
define  PNCTl.EQ.AR.SN. ITEHPTR.PR 
DATA  NPTRS/2/ 

EXECUTE 

INITIALIZE  VARIABLES 
PI1I>AR 
P(Z)sSN 
PEQiZLEa 
ISTACK  X 3 
■SET  EOCUR  TO  EQIN 
EQCUR  > EOIN 
■PLACE  EQCUR  ON  STACK 
10  ISTACK  > ISTACK  * 1 
STACKIISTACKI  > EQCUR 

PERFORH  PREOROER  TRAVERSAL  TO  TERHINAL  NODES 
■FETCH  THE  POINTERS  FROH  EQCUR  TO  EACH  OF  THE  POSSIBLE  P BLOCKS.  SEC 
■NHICH  IS  EQUAL  TO  NOTONE.  AND  SET  THE  PROPER  IPIISTACKI  TO  THE  SUN  OF 
■THE  PROPER  IPV'S. 

•DOES  EQCUR  HAVE  ANY  SUB-EQ*ST  FETCH  THE  DOHN  POINTERS  OF  EQCUR 
NO  EQCURyEQ/50  'EQCUR/IO 

■EQCUR  DOES  NOT  HAVE  SUB-EQ<S.  HON  HANY  BLOCKS  ARE  IN  STACK, 
so  IFdSTACK  .EQ.lt  GO  TO  110 

■FOLLONING  LOOP  DELETES  ALL  BACK  POINTERS  TO  EQCUR 
00  00  I^I.NPTRS 
PTR»P(II 

■FETCH  VALUE  OF  PTR  OF  EQCUR  AND  PLACE  IT  IN  PTCUR 
EaCUR*PTR/99  'PTCUR 
lOPTRxEQ 

IFtPTR.EQ.SNI  IDPTRxITENPTR 

■NON  HUST  DELETE  EQCUR  FROM  THE  EQ  PTRS  OF  PTCUR.  FIRST  MUST  FIND 
■NHICH  OCCURRENCE  OF  EO/PTCUR  IS  EQUAL  TO  EQCUR.  FETCH  ALL  EQ 
■OCCURRENCES 

■LOOP  TO  SEE  NHICH  OCCURRENCE  IS  EOCUR  AND  THEN  DELETE  IT. 

■EQCUR  IS  THE  KTH  OCCURRENCE  IN  EQ/PTCUR.  DELETE  IT. 

K^O 

SO  PTCUR»I0PTR/99(.~K>K'l’*  >EQCUR/60 .-.Kl 
SO  CONTINUE 

DELETE  TERNINAL  BLOCK  EQCUR  FROM  SHIP  DESIGN  FILE 
E QCUR*L  VN ANE ' HOLNAN 
CALL  COHRLDRISLDELETB.IERR.HOLNAMI 
IFIIERR.NE.OI  CALL  ERRISHDELETB.IERRI 
C-SET  EQCUR  TC  NEXT  BLOCK  ON  STACK 
ISTACK  > ISTACK-1 
EQCUR  : STACK (ISTACKt 

C-OELETE  EQLST  FROH  EQ/EQCURIOONN  POINTER!  FIRST  FETCH  ALL  BONN 
C-POINTERS  EQ/EQCUR 
6 EQCURYEO-.l 
60  TO  NO 

C-ONLY  1 BLOCK  LEFT  ON  STACK.  FIRST  SET  EQPAR  TO  THE  PARENT  OF  EQIN 
C IS  PARENT  AN  EQ  BLOCK 
6 110  EQIN«PR/99  'PARENT'LVNAHE 'EQPAR 

ARRAY1>  EOPAR.ANO.T7770000000000000000B 
IFIARRATl.NE.PEQt  GO  TO  INO 

IS  AN  EQ  BLOCK.  LOOP  TO  DELETE  BACK  POINTERS  TO  IT. 

C DELETE  POINTER  FROM  PARENT  TO  EQIN 
I.O 

6 130  PARENT'EQI.'I'I'l'/BB  •EQCUR/130.-.I> 

6 INO  EQCURyLVNANE'HOLNAH 

CALL  CONRLOR(6LOELETB.IERR.HOLNANI 
C-FINISHEO-RETURN 
RETURN 

C DESIRED  POINTER  NOT  FOUND  - ERROR 
99  CALL  ERRISHFETCH.IERR) 

I 6 COMPLETE 
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SUBROUTINE  OLEQPT  ICQINiPTRI 

SIVEH  AN  EQ  BLOCKIEOINI  AND  A POINTER  TVPEIPTRI  TO  ANOTHER  BLOCK. 

-TNIS  ROUTINE! 

1-  DELETES  THE  POINTER  TO  THE  OTHER  BLOCK 

2-  DELETES  THE  BACK  POINTER  FROH  THE  OTHER  BLOCK  TO  THE  EQ 
BLOCK 

3-  UPDATES  POINTERS  FRON  AND  BACK  POINTERS  TO  H16HER  EQ 
BLOCKS  AS  NECESSARY  TO  NAINTAIN  THE  HIERARCHICAL  SEOUEHCC 
OF  (NOTONE'S.  real  pointers,  and  C LINBO'S. 

INTEGER  EQIN.HOLNAH.PEa.PTR.ARRAri.EaCUR.PTCUR.AR.OArA.EO.PNOri. 

» PTRNAH. SANE. TEHPNAN. ARRAY, BN. ELEH.EaLST.PLINBO.PR.PTLST.PTRIN. 

» PTRSU8.SH 
COHHON  /NANE/  LVNAHE 
CONNON/UNITS/LFN,  ICONN 

COHHON  /NODES/  PNOTl.EO.AR.SH.ITEHPTR.PR 
C 

6 EXECUTE 

C-INITIALIZE  VARIABLES 
PEO^ZLEQ 

PLIN80  s GHLINBO 
ELENbEO 

IFIPTR.EO.SHI  ELEN>I«TEHPTR 

C-FETCH  THE  PTR  OF  EQIN  AND  PLACE  ITS  VALUE  IN  PTRIN 
6 EQIN*PTR/99  'PTRIN^LVNAHE 'PTRNAH 

C*IS  PTRIN  A LIHBO  BLOCK 

TEHPNAH^SHIFT (PTRNAH, 121 
IF(TEHPNAN.NE.PLIH80>  60  TO  $ 

C-PTRIN  IS  A LIHBO  BLOCK.  BEFORE  RETURNING  DELETE  EOCUR  AS  AN  EO/PTR 
C>OF  PTRIN.  FIRST,  FETCH  ALL  EO/PTRS  OF  PTRIN 
C-OELETE  EOCUR  FROH  EO/PTRIN 
I*t 

6 2 PTRINyELEH/99  (.“I*!*!-  >EaiN/2,-.It 
RETURN 

C-SET  PTCUR  AND  EOCUR 
S PTCUR  • PTRIN 
EOCUR  > EOIN 

C'OELETE  PTR/POINTER  OF  EOCUR  TO  PTCUR 
C-SET  EOLST  TO  EOCUR 

C-GET  NEH  EOCUR  BY  FETCHING  PARENT  OF  CURRENT  EOCUR  AND  PLACING  ITS 
c-value  in  EOGUR 

6 It  EOCUR'EOLST  (-PTR,*PR'EOCUR*LVNANE'HOLNAHI 
C-HHAT  IS  THE  BLOCKTYPE  OF  EOCUR 

ARRA Yl-HO LNAH. AND. 777701000 to toot OOOOtB 
C-EQCUR  IS  NOT  AN  EO  BLOCK  TYPE-OONE-RETURN 
IF(ARRAY1.NE.PE0I  RETURN 

C-EOCUR  IS  AN  EO  BLOCK  TYPE.  SET  PTLST  TO  PTCUR 
PTLST  > PTCUR 

C-SET  A NEH  PTCUR  BY  PLACING  IN  IT  THE  VALUE  OF  PTR  C~  EOCUR 
C E0CUR*PTR/99  'PTCUR^PTRIN/SO 

C-THE  VALUE  OF  PTCUR  IS  PTRIN.  GET  THE  NUHBER  OF  BONN  POINTERSIEO'SI  OF 
C-BLOCK  EOCUR. 

C-LEN6TH  IS  1.  SO  GO  BACK  .SET  EOCUR.ETC..  AND  GET  NEXT  ONE. 

C-LENGTH  GT  1.  OONE--RETURN 
C-LEN6TH  IS  LT  1— ERROR— STOP 
G EBCUR*C0/9t  .2/10/RETURN 

90  HRITE(IC0NH.2tl 

20  FORHATdH  .SOHERROR-EO'S  OF  EOCUR  NUST  EXIT  > 

CALL  COHRLORIALFLFN.IERR.LFNI 
IFClERR.NE.tl  CALL  ERRIAHFLFH, lERR) 

STOP 

.♦.BHB  VALUE  OF  PTRIN  IS  NOTONE.  SET  IDO  TO  ZERO 
30  100  • 0 

C-IS  PTLST  EOUAL  TO  NOTONE 

IFIPTLST.EO.PNOTlt  CO  TO  00 

C-PTLST  IS  NOT  NOTONE.  DELETE  EOLST  FROH  EO  PTRS  OF  PTLST.  FIRST  HUST 
C-FETCH  ALL  EOCS  FROH  PTLST 
C-NOH  TRY  TO  DELETE  EOLST 
I-O 

6 70  PTLST«ELEH/I»0  (.••I»I*1“«EOLST/70,-.I» 

GO  TO  00 
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C-^PTLAT  DOES  NOT  HAVE  ANV  EO  POINTERS  OR  EOLST  IS  NOT  AN0N6  THOSE  THAT 
C-ARE  THERE.  ERR0R--A80RT 
%0  NRITEdCONH.SOI 

SO  FORHATdH  .3SHEQLST  HAS  NOT  THERE  TO  OELETE'ABORT  I 
call  COHRLORCALFLFN.IERR.LFNI 
IFIIERR.NE.OI  CALL  ERRUHFLFN.IERRI 
STOP 

C'EQLST  NOT  AMONG  EO'S  OF  EOCUR.  NEED  TO  KNOM  HOH  MANY  THERE  AREILENI 
6 •(  EaCUR*EQ/99  .Z/S5/t2l 

C-LEN  IS  ONE.  MUST  DELETE  EOLST  FROM  EQ'S  OF  PTCUR 

C-  IF  PTCUR  DOES  NOT  HAVE  ANT  EO  POINTERS  OR  EOLST  IS  NOT  AMONG  THOSE 
C-EO'S  that  00  EXIST.  ERROR- ABORT 
•9  I«9 

G til  PTCUR^ELEM/VII.-IxI*!-  /AI  >EQLST/ltO.-.II 
GO  TO  170 

C-LEN  IS  GREATER  THAN  ONE  NON  HAVE  LOOP  TO  SEE  ABOUT  THE  PTR  OF  EACH 
C-SUBEO  OF  EOCUR 

C-SEE  IF  THE  ITH  SUBEO  IS  EOLST.  IF  IT  IS  CONTINUE 
120  I«0 

G 121  E0CUR*E0/99  .’’I>I»1*‘/1A0  xE0LST*BN//121 
C-CHECK  ON  100 

lFltOO.NE.il  GO  TO  ISO 

C-tOO  IS  ZERO.  SET  IT  TO  ONE  AM  SET  SANE  TO  PTR  OF  OATAIII 
100  « 1 

6 BN«PTR*SAHE 
60  TO  lAO 

C-IOO  MAS  NOT  ZERO.  SET  PTRSUB  TO  PTR  OF  OATAIII 
C-IF  PTRSUB  IS  NOT  EOUAL  TO  SANE.  DONE— RETURN 
6 ISO  BN*PTR/99*PTRSUB«SANE/RETURN/121 
C-IF  SAME  IS  NOTONE.  DONE— RETURN 
111  IFISAHE.EO.PNOTII  RETURN 

C-SAME  IS  NOT  NOTONE.  MUST  DELETE  EO  OF  SANE  POINTERS  FROM  ALL  EOCS 
C-UNOER  PARENT I EQCURI.  FIRST.  HAVE  ALL  EOCS  OF  EOCUR  FROM  ABOVE  IN 
C-ARRAT  DATA.  NEXT.  MUST  FETCH  ALL  EO  PTRS  OF  SAME. 

I>l 

6 151  EQCUR*EQ/99  .~1>1»1~/160  'DATA 

C-NON  60  THROUGH  PROCESS  OF  DELETING  FROM  SANE  ALL  EO  PTRS  HHICH  ARE 
C-SUBEO 'S  OF  EOCUR 
111  J*0 

G 195  SAME«ELEH/17II.-J«J»1’*/1SO«OATA/19I.-.JI 
GO  TO  ISI 

C-AOO  EOCUR  AS  AN  EO  POINTER  OF  SAME 
171  IFIPTR.NE.SHI  GO  TO  179 
ARRAV«1TEHPTR 
60  TO  171 
175  ARRAT^EO 
6 171  SANE  ARRAY  EOCUR 
C-SET  PTR  OF  EOCUR  TO  SAME 
6 EOCUR  PTR  -.1  SAME 

C-SET  EOLST  TO  EOCUR 
EOLST  « EOCUR 

C-SET  VALUE  OF  EOCUR  TO  THE  PARENT  NAME  OF  THE  PRESENT  EOCUR 
6 EOCUR»PR/99«EOCUR*LVNAHE'HOLNAH 

C-EOCUR  IS  NOT  AN  EO  BLOCK-DONE— RETURN 

ARRAYl>HOLNAN.AN0.7777BBIOtllOIOOIOIIIB 
IFIARRAYl.NE.PEOI  RETURN 

ii»i»OBMO  IS  AN  EO  BLOCK.  SET  PTCUR  TO  PTR  OF  EOCUR 
G E0CUR*PTR/99*PTCUR 

C-GO  TO  MNERE  GETTING  THE  SUBEO'S  OF  EOCUR  AND  RESUME  PROCESS  FROM 
C-THERE . 

GO  TO  •• 

C DESIRED  POINTER  NOT  FOUND  - ERROR 
99  CALL  ERRI5HFETCH.IERRI 
G COMPLETE 

/ COMPLETE 


AS  CODED  IN  FORTRAN  FOR  GIRS 


XHIS  PAOE  IS  BEST  QUALITY  FBACXICABU 
FROU  OOiPY  FURNISHED  TV  DD.Q  


sumouriNC  ocleq  orr>i  rouno>«/  tmcc 


FTM 


SUSROUTINE  OCLEQIEQIN) 

COMMON  /IVEIiOS/  LVFUNCtLWERCtLVVMOS.LVVT VM.LWVEL. 

• LVVNVL.LVSKlM«LmR*LVVlNC«LVV«.S  till. LVTTMEt  til 
C 

C-TNIS  ROUTINE  DELETES-  «N  EQ  BLOCKIEOINI  IHO  ILL  SUBOLOCKS  FROM  THE 
C'SHIF  OESICN  FILE.  AMO  DELETES  ALL  POINTERS  TO  THOSE  BLOCRS. 

C 

INTECER  EaiN.HOLNAH.PEQ.PTR.ARRAVt.EOCUR.PTCUR.P.EaPAR.PARENT. 

» STACK 

COMMON  /NAME/  LVNAME 

COMION  /NODES/  PNOTl  .EO.  AR.SH.  ITEHPTR.PR 

OIHENSION  FIEI.STACXfllll 

INTECER 

*PNOTl.EO. AR.SH. ITEHPTR.PR 
DATA  NPTRS/Z/ 

CALL  LVGRNIPMOTl  I 
CALL  LMCRNlkO  I 

CALL  LVCRNIAR  I 

CALL  LVCRNISH  I 

CALL  LTCRNIITEMPTI 
CALL  LVSRNfPR  I 
CO  TO  2SIB1 
2SIBI  CONTINUE 
C-IHITIALIZE  VARIABLES 
Plll-AR 
PtZMSM 
PEO-ZLEO 
ISTACK  ■ • 

C-SET  EOCUR  TO  EOIN 
EOCUR  > EOIN 
C-PLACE  EOCUR  ON  STACK 
IB  ISTACK  « ISTACK  * 1 
STACKCISTACKt  ■ EOCUR 

C PERFORN  PREOROER  TRAVERSAL  TO  TERNIHAL  NODES 

C-FETCH  THE  POINTERS  FROM  EOCUR  TO  EACH  OF  THE  POSSIBLE  P BLOCKS.  SEE 
C-MHICH  IS  EQUAL  TO  NOTOME.  AND  SET  THE  PROPER  IPIISTACKI  TO  THE  SUN  OF 
C-THE  PROPER  IPV'S. 

C'OOES  EOCUR  HAVE  ANT  SUB-EQ'ST  FETCH  THE  OOHN  POINTERS  OF  EOCUR 
At  CONTINUE 

CAI  £OCUR»EO/BI  •EOCUR/ll 
LVVAL-EOCUR 
LVVARC>LVVAL 
LVFUNC-EO 
CALL  LVFINO 

IFILVVTR  .EO.  -11  CO  TO  SB 
EQCUR-LVVAL 

IFtLVVTR  .NE.  -II  CO  TO  II 

C-EOCUR  DOES  HOT  HAVE  SUB-EQ*S.  HON  NAHT  BLOCKS  ARE  IN  STACK. 

11  IFtlSTACK.EO.ll  CO  TO  111 
C-FOLLOMINC  LOOP  DELETES  ALL  BACK  POINTERS  TO  EOCUR 
00  18  I«1.NPTRS 
PTR-Ptll 

C-FETCH  VALUE  OF  PTR  OF  EOCUR  AND  PLACE  IT  IN  PTCUR 
C EQCUR*PTR/B9  'PTCUR 
LVVAL-EQCUR 
LVVARC>LVVAL 
LVFUHC«PTR 
CALL  LVFINO 

IFtLVVTR  .EO.  -II  CO  TO  99 

PTCURoLVVAL 

lOPTR-EO 

IFtPTR.EQ.SW  lOPTRmlTENPTR 
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C-NOM  NUSr  delete  EQCUR  from  the  EQ  FTRS  Of  FTCUR.  FIRST  HOST  FIHO 
C-MHICH  OCCURRENCE  OF  EO/FTCUR  IS  EQUAL  TO  EQCUR.  FETCH  ALL  EQ 
C-OCCURRENCES 

C-LOOF  TO  SEE  HHtCH  OCCURRENCE  IS  EQCUR  AND  THEN  DELETE  IT. 

C>EQCUR  IS  THE  KTH  OCCURRENCE  IN  EQ/FTCUR.  DELETE  IT. 

K>t 

At  CONTINUE 

C«a  FTCUR*I0FTR/99(.''K«K«t**  ■EQCUR/AI.'.K* 

LyVAL>FTCUR 
LVVARC>LVVAL 
LVFUNC-IOFTR 
CALL  LVFINO 

IFtLVVTR  .EQ.  -II  CO  TO  99 

LVV  1>LVVAL 

LVV  2>LVFUNC 

LVV  3«LVVARC 

K«K*1 

LVVFOS>  K 

CALL  LVFNVtLV  II 

LVVTRa-1 

IFtLVVAL  .EQ.  EQCUR 
*1  LVVTR>1 

IFILVVTR  .EQ.  -II  CO  TO  Cl 
LVFUNC«LVV  2 
LVVARG>LVV  3 
CALL  LVFINO 
LVVPOS>  K 
CALL  LVFNVILV  21 
CALL  LVDLTI 
II  CONTINUE 

C DELETE  TERNINAL  BLOCK  EQCUR  FRON  SHIF  DESIGN  FILE 
C EQCUR^LVHAHE'HOLNAN 
LVVAL*EQCUR 
LVVARC>LVVAL 
LVFUNC-LVNAHE 
CALL  LVFINO 
HOLNAH>LVVAL 

CALL  COHRLOR(CLOELETB.IERR.HOLNANI 
IFIIERR.NE.il  CALL  ERRUHOELETB.IERRI 
C-SET  EQCUR  TO  NEXT  BLOCK  ON  STACK 
ISTACK  ■ tSTACK-1 
EQCUR  « STACK* ISTACKI 

C-OELETE  EQLST  FROH  EQFEQCURCOONN  FOINTERI  FIRST  FETCH  ALL  DONN 
C-FOIHTERS  EQ/EQCUR 
C EQCUR*EQ-.l 
LVVAL'EQCUR 
LVVAROLVVAL 
LVFUNC-EQ 
CALL  LVFINO 
CALL  LVFNVILV  31 
CALL  LVDLTI 
CO  TO  M 

C-OHLT  1 BLOCK  LEFT  OH  STACK.  FIRST  SET  EQFAR  TO  THE  FARENT  OF  EQIN 
C IS  PARENT  AN  EQ  BLOCK 
111  CONTINUE 

Cill  EQtN*FR/99  ‘PARENT *LVNAHE* EQFAR 
LVVAL«EQ1N 
LVVARC-LVVAL 
LVFUNC>FR 
CALL  LVFINO 

IFILVVTR  .EQ.  -II  GO  TO  99 

FARENT-LVVAL 

LVVARCaLVVAL 

LVFUNCaLVNAHE 

call  LVFINO 

EQFAR-LVVAL 

ARRATla  EQFAR. ANO. 7777IIIIIIIIIIIIIIIIB 

IFIARRATl.NE.FEQI  CO  TO  Ul 
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C'EaPAR  IS  AN  EQ  BLOCK.  LOOP  TO  DELETE  BACK  POINTERS  TO  IT. 
C DELETE  POINTER  FROH  PARENT  TO  EOIN 
1*0 

130  CONTINUE 

135  C130  PARENT ♦EQI.“I*I*1”/SS  ■EOCUR/130.*.lt 

LVVAL* PARENT 
LVVARC>LVVAL 
LVFUNC*Ea 
CALL  LiriNO 
lAO  LVV  1*LVVAL 

LVV  2>LVFUNC 
LVV  3*LVVAR6 
I»l*l 

LVVPOS*  1 

1A5  CALL  LVFNVILV  A) 

IFILVVTR  .EQ.  -11  60  TO  99 

LVVARG*LVVAL 

LVVTR*-1 

IF (LVVAL  .EQ.  EOCUR 
150  *1  LVVTR*! 

IFILVVTR  .EQ.  -1>  GO  TO  130 
LVFUNC*LVV  Z 
LVVAR6«LVV  3 
CALL  LVFINO 
155  LVVPOS*  I 

CALL  LVFNVILV  51 
CALL  LVOLTI 
140  CONTINUE 
C140  EQCURALVNAHE'HOLNAN 
160  LVVAL*EaCUR 

LVVARG*LVVAL 
LVFUNC*LVNANE 
CALL  LVFINO 
HOLNAH*LVVAL 

165  CALL  COHRLDRIALOELETB.IERR.HOLNAHt 

C-FINISHEO'RETURN 
RE  TURN 

C DESIRED  POINTER  NOT  FOUND  - ERROR 
99  CALL  ERRISHFETCH.IERRI 

ITO  RETURN 

Z5001  CONTINUE 

LV  1*0 
LV  Z*0 
LV  3*0 

175  LV  4*0 

LV  5*0 
GO  TO  25000 
END 


STATISTICS 

PROGRAN  LENGTH  547B  359 

CN  LABELED  COHNON  LENGTH  44B  36 
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subroutine  OLEQPKEOINtPTRI 

COHHON  /LVAR6S/  LVFUNCtLVVARCtLVVPOS.LVVTVPtLVVAL* 
*LVVNVL.LVSKIP.LVVTR,LVVINC,LVVALS(tSi.LVTVPe<itl 
C 

C-6IVEN  AN  EO  BLOCKtCOINI  ANO  A POINTER  TTPEIPTRI  TO  ANOTHER  BLOCK. 
C-THIS  ROUTINE! 

C*  1-  DELETES  THE  POINTER  TO  THE  OTHER  BLOCK 

C-  2-  DELETES  THE  BACK  POINTER  FRON  THE  OTHER  BLOCK  TO  THE  EB 

C-  BLOCK 

C-  3>  UPDATES  POINTERS  FRON  AND  BACK  POINTERS  TO  HICHER  EO 

C-  BLOCKS  AS  NECESSARY  TO  HAINTAIN  THE  HIERARCHICAL  SEQUENCE 

C-  OF  {NOTONE'S.  REAL  POINTERS.  ANO  C LINBO'S. 

C 

INTECER  EQIN.HOLNAN.PEa.PTR.ARRAn.EOCUR.PTCUR.AR. DATA. EO.PNOTl. 

* PTRNAH.SAHE.TEHPNAH. ARRAY. BN. ELEN.EQLST.PLIHBO.PR.PTLST.PTRIM. 

* PTRSUB.SH 

COHHON  /NAHE/  LVNANE 
COHHON/UNI TS/LFH. ICONH 

COHHON  /NODES/  PHOTl.EQ.AR.SH. ITEHPTR.PR 
C 

60  TO  2S0tl 
2StBt  CONTINUE 
C-INITIALIZE  VARIABLES 
PEa>2LEa 

PLIHBO  * 6HLIHB0 
ELEH*EQ 

IFIPTR.EQ.SHI  ELEN-ITENPTR 

C'FETCH  THE  PTR  OF  EQIH  ANO  PLACE  ITS  VALUE  IN  PTRIN 
C EQIN*PTR/BB  'PTRINyLVHAHE'PTRNAH 
LVVAL>EaiN 
LVVAR6>LVVAL 
LVFUNC'PTR 
CALL  LVFINO 

IFILVVTR  .EQ.  -11  60  TO  BB 

PTRIN>LVVAL 

LVVAR6>LVVAL 

LVFUNC>LVNAHE 

CALL  LVFINO 

PTRNAH*LVVAL 

C-IS  PTRIN  A LIHBO  BLOCK 

TEHPNAN>SHIFT  I PTRNAH.12I 
IFCTEHPNAH.HE.PLIHBOI  60  TO  S 

C-PTRIN  IS  A LIHBO  BLOCK.  BEFORE  RETURNIN6  DELETE  EOCUR  AS  AN  EQ/PTR 
C-OF  PTRIN.  FIRST.  FETCH  ALL  EQ/PTRS  OF  PTRIN 
C-OELETE  EQCUR  FROH  EQ/PTRIN 
I>t 

2 CONTINUE 

C2  PTRIN*ELEN/BB  l.'I-I*!*  ■EaiN/2.-.II 
LVVAL>PTR1N 
LVVAR6*LVVAL 
LVFUNC>ELEN 
CALL  LVFINO 

IFILVVTR  .EQ.  -II  60  TO  BB 

LVV  1*LVVAL 

LVV  2*LVFUNC 

LVV  3-LVVAR6 

I»I»1 

LVVPOS*  I 

CALL  LVFNVILV  11 

LVVTR>-1 

IFILVVAL  .EQ.  EQIN 
*1  LVVTR*! 

IFILVVTR  .EQ.  -II  60  TO  2 

LVFUNC>LVV  2 

LVVAR6*LVV  3 

CALL  LI^INO 

LVVPOS*  I 

CALL  LVFNVILV  21 

CALL  LVOLTI 

RETURN 
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C-SET  PTCUR  AND  EOCUR 
5 PTCUR  « PTRIN 
EQCUR  > ERIN 

C-DELETE  PTR/POINTER  OF  ERCUR  TO  PTCUR 
C'SET  EQLST  TO  ERCUR 

C*6ET  NEH  ERCUR  BT  FETCHIN6  PARENT  OF  CURRENT  EOCUR  AND  PLACIN6  ITS 
C-VALUE  IN  EOCUR 
ta  CONTINUE 

CIO  ERCUR«ERLST  (-PTR.aPR'EOCUR^LVNANE'HOLNAHI 
LVVAL>ERCUR 
LVVARC«LVVAL 
E0LST«LVVAL 
LVV  l«LVVARe 
LVFUNC«PTR 
CALL  LVOLET 
LyVAL<LVV  1 
LVVARC>LVVAL 
LVFUNC^PR 
CALL  LKFIND 
ERCUR«LVVAL 
LVVARC«LVVAL 
LVFUNC«LVNANE 
CALL  LyFIND 
HOLNANxLVVAL 

C-HHAT  IS  THE  BLOCKTYPE  OF  EOCUR 

ARRAVlxHOLNAH.ANO.TTTTaiaaBatBaBOBaBBSB 
C-ERCUR  IS  NOT  AN  ER  BLOCK  TYPE- DONE -RE TURN 
IFtARRAYI.NE.PEOI  RETURN 

C-ERCUR  IS  AN  EO  BLOCK  TYPE.  SET  PTLST  TO  PTCUR 
PTLST  « PTCUR 

C-SET  A NEN  PTCUR  BY  PLACINS  IN  IT  THE  VALUE  OF  PTR  OF  E«UR 
C ERCUR*PTR/B9  •PTCUR>PTRIHF3t 
LVVAL«EOCUR 
LVVARG<LVVAL 
LVFUNC«PTR 
CALL  LVFINO 

IFILVVTR  .ER.  -tl  CO  TO  94 

PTCUR>LVVAL 

LVVARCoLVVAL 

LVVTR>-1 

IFtLVVAL  .EO.  PTRIN 
*1  LVVTRal 

IFILVVTR  .ER.  -II  CO  TO  SB 

C-THE  VALUE  OF  PTCUR  IS  PTRIN.  CET  THE  NUNBER  OF  OOHN  POINTeRSIER*SI  OF 
C-BLOCK  EOCUR. 

C-LENCTH  IS  It  SO  CO  BACK  tSET  ERCUR.ETC.t  AND  CET  NCKT  ONE. 

C-LENCTH  CT  1,  DONE— RETURN 
C-LENCTH  is  LT  1— ERROR--STOP 
C E0CUR«EB/9a  .2/10/RETURN 
LVVAL>ERCUR 
LVVARG<LVVAL 
LVFUNC>ER 
CALL  LVFINO 

IFILVVTR  .EO.  -II  CO  TO  90 

LVVPOS<  2 

CALL  LVFNVILV  31 

IFILVVTR  .EO.  -II  GO  TO  .. 

IFILVVTR  .NE.  -II  RETURN 

90  NRITEIICONH.20I 

20  FORHATIIH  .30HERROR-EO*S  OF  EOCUR  HUST  EXIT  I 
CALL  COHRLORI9LFLFN.IERR.LFNI 
IFIIERR.NE.OI  CALL  ERRUHFLFN. lERRI 
STOP 
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THIS  PAQB  rS  BEST  QUAIITT 
KgOM  QOiFY  FUKNXSU£a3 10  OD,Q 


C-THE  VALUE  OF  PTRtN  IS  NOTOME.  SET  IDO  TO  ICM 
13S  30  100  ■ 0 

C-IS  PTLST  EQUAL  TO  NOTONE 

IFIPTLST.EQ.PNOTII  SO  TO  SI 

C-PTLST  IS  NOT  NOTONE.  DELETE  CQLST  FROM  ED  PTRS  OF  PTLST.  FIRST  MUST 
C'FETCH  ALL  EQfS  FROM  PTLST 
LAI  C'NON  TRY  TO  DELETE  EQLST 

I«0 

PI  CONTINUE 

CPI  PTLST*ELEN/AI  l.'■I■I*L~>EaLST/PI«-.II 

LVVAL« PTLST 

LAS  LVVARC<LVVAL 

LVFUNCxELEH 
CALL  LVFINO 

IFILVVTR  .EQ.  -II  60  TO  Al 
LVV  1«LVVAL 

111  LVV  2«LVFUNC 

LVV  3«LVVAR6 
I>I»1 

LVVPOS>  I 
CALL  LVFNVILV  Al 
1S5  LVVTRa-t 

IFILVVAL  .EQ.  EQLST 

♦ I LVVTR-l 

IFILVVTR  .EQ.  -II  60  TO  PI 
LVFUNC«LVV  2 
161  LVVAR6«LVV  3 

CALL  LVFINO 
LVVPOS«  I 
CALL  LVFNVILV  SI 
CALL  LVOLTI 

165  60  TO  SI 

C-PTLAT  DOES  NOT  HAVE  ANT  EQ  POINTERS  OR  EQLST  IS  NOT  AN0N6  THOSE  THAT 
C-ARE  THERE.  ERROR— ABORT 

Al  MRITEIICONH.50I 

SI  FORMAT IlH  .SSHEQLST  HAS  NOT  THERE  TO  OELETE-ADORT  I 

IPI  CALL  COHRLORIALFLFN.  KRR.LFNI 

IFIIERR.NE.OI  call  ERRIAHFLFN.IERRI 
STOP 

C-EQLST  NOT  AN0N6  EQ*S  OF  EQCUR.  NEEO  TO  KNOH  HON  NAMT  THERE  AREaENI 
SO  CONTINUE 

IPS  CID  EQCUR*EQ/99  .2/15/120 

LVVAL>EQCUR 
LVVARC>LVVAL 
LVFUNC^EQ 
CALL  LVFINO 


111 

IFILVVTR  .EQ. 

-11 

60 

TO 

99 

LVVPOS> 

2 

CALL  LVFNVILV 

61 

IFILVVTR  .EQ. 

-11 

60 

TO 

IS 

IFILVVTR  .NE. 

-11 

60 

TO 

121 
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ms  PAOE  IS  SSSI  QUM>m 
raOMOOPyPURHlSUBDIOllDC 


IW  C'LeH  IS  ONE.  HOST  OCLETE  EQLST  MON  EO'S  OF  FTCUN 

C-  IF  FTCUR  DOES  NOT  HIVE  ENT  E«  FOINTEKS  0*  EOLST  IS  NOT  EN0N6  THOSE 
C>EQ*S  THAT  00  EXIST.  EMON-EMRT 


AS 

i«i 

111 

CONTINUE 

IBS 

cm 

PTCUR»CLEH/AI(.'‘IaI»l*‘  /Al 
LVVAL-PTCUR 

LVVARCaLVVAl 

LVFUNC«ELEH 

CALL  LVFINO 

<E0LST/11I,-.1I 

19$ 

IFILVVTR  .EO.  -11  CO  TO 

LVV  1«LVVEL 

LVV  Z<LVFUNC 

LVV  S-LVVARC 

I«I*1 

AO 

ZOS 

LVVPOS*  I 

CALL  LVFNVILV  71 

IFILVVTR  .EO.  -11  CO  TO 

lvvarc«lvval 

LVVTR>-1 

At 

ZOS 

IFILVVAL  .EO.  EOLST 

*\  LVVTRmt 

tFILVVTR  .EQ.  -tl  CO  TO  ilO 
LVFUNC>(.VV  Z 
LVVARC«LVV  3 

Zl»  CELL  LVFINO 

LVVPOS>  I 
CELL  LVFNVCLV  SI 
CELL  LVOLTI 
CO  TO  17E 

Z15  C-LEN  IS  CREATES  THEN  ONE  NON  HAVE  LOOP  TO  SEE  ABOUT  THE  PTR  OF  EACH 

C'SUBEO  OF  EOCUR 

C-SEE  IF  THE  ITH  SUBEQ  IS  EOLST.  IF  IT  IS  CONTIHUE 
IZA  I>A 
IZl  CONTINUE 

ZZt  ClZl  EQCUR*EO/OB  .~I«I»1'*/1AI  >EaLST«BNF/iZl 

LVVAL«EaCUR 
LVVARG>LVVAL 
LVFUNCsEO 
CALL  LVFINO 


zzs 

IFILVVTR  .EO. 

-11  CO 

TO 

99 

I>I*1 

LVVPOSs  I 

CALL  LVFNVILV 

91 

IFILVVTR  .EO. 

-11  CO 

TO 

lAI 

Z3f 

LVVARC>LVVAL 
LVVTRa-1 
IFILVVAL  .EO. 

EOLST 

*1  LVVTR>1 

Z39 

BN'LVVAL 
IFILVVTR  .NE. 

-11  CO 

TO 

IZl 

C-CHECK  ON  too 

IFlIOO.NE.tl  CO  TO  LSI  ....... 

C-IOO  IS  ZERO.  SET  IT  TO  ONE  ANO  SET  SANE  TO  PTR  OF  OATAfll 
100  « i 

2M  C eN*PTR<SAHE 

LVVAL>aN 
LVVARC«LVVAL 
LVFUNC>PTR 
CALL  LVFINO 
SAHE>LVVAL 
GO  TO  LAI 
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-as  MM  IS  »»si  <IU*II« 

jgyy  oopY  yypftisHBD  rODDjQ  - 


C-IDO  HAS  NOT  ZCRO.  SET  NTRSUB  TO  PTR  OF  OATAltl 
C'lF  PTRSUB  IS  HOT  EQUAL  TO  SANE.  DONE— RETURN 
I SB  CONTINUE 

ClSa  8N*PTR/99'PTRSUB«SAHE/flETURN/121 
LVVAL>BN 
LVVARC>LVVAL 
LVFUNC>PTR 
CALL  LVFINO 

IFILVVTR  .EQ.  -tl  60  TO  99 

PTRSUB«LtfVAL 

LVVAR6«LVVAL 

LVVTRs-1 

IFILVVAL  .EQ.  SANE 
*1  LVVTR«1 

IFILyVTR  .EQ.  -II  RETURN 

IFILVVTR  .NE.  -11  60  TO  121 

C-IF  SANE  IS  NOTONE*  DONE-RETURN 
lAO  IFISANE.EQ.PNOTII  RETURN 

C-SAHE  IS  NOT  NOTONE.  HUST  DELETE  ED  DF  SANE  PDINTERS  FRDN  ALL  EQCS 
C-UNDER  PARENT lEDCURI.  FIRST*  HAVE  ALL  EQCS  OF  EQCUR  FRON  ABOVE  IN 
C-ARRAV  DATA.  NEXT*  HUST  FETCH  ALL  EQ  PTRS  OF  SANE. 

I>0 

ISa  CONTINUE 

ClSa  EQCUR»EQ/99  .’■t>I*l~/lBa  ‘DATA 
LVVAL* EQCUR 
LVVAR6<LVVAL 
LVFUNC-EQ 
call  LVFINO 

IFILVVTR  .EQ.  -II  60  TO  99 
1»I*1 

LVVP0S>  I 

call  lvfnvilv  lai 

IFILVVTR  .EQ.  -II  60  TO  169 

OATA«LVVAL  „ 

C-HOH  60  THROUCH  PROCESS  OF  0ELETIN6  FROH  SANE  ALL  EQ  PTRS  NHICH  ARE 
C-SUBEQ*S  OF  EQCUR 

169  j>a 

1S9  CONTINUE 

ClfS  SAHE*E^H/17a  l.~>>J*l~/lSa«OATA/lSa*-.  Jl 

LVVAR6«LVVAL 
LVFUNC<ELEN 
CALL  LVFINO 

IFILVVTR  .EQ.  -II  60  TO  170 

LVV  1«LVVAL 

LVV  2«LVFUNC 

LVV  3>LVVAR6 

J*J«1 

LVVPOS*  J 

CALL  LVFNVILV  111 

IFILVVTR  .EQ.  -II  60  TO  ISA 

LVVAR6-LVVAL 

LVVTR«-1 

IFILVVAL  .EQ.  DATA 
*1  LVVTRal 

IFILVVTR  .EQ.  -II  60  TO  ISB 

LVFUNC>LVV  2 

LVVAR6>LVV  3 

CALL  LVFINO 

LVVPOS>  J 

CALL  LVFNVILV  121 

CALL  LVOLTl 

60  TO  isa 

C-ADO  EQCUR  AS  AH  EQ  POINTER  OF  SANE 
17a  IFIPTR.NE.SHI  60  TO  179 
ARRAT>ITEHPTR 
60  TO  179 


I LVV«LSUI-E«CUR 

I CALL  LWtSRT 

N C>SET  PTR  OF  EOCUR  TO  SAME 

C EOCUR  PTR  -.1  SANE 

m LVVAL>E(|CUR 

LWARG^LWAL 
LVFUMC>PTR 
CALL  LVFINO 
CALL  LVFNVILV  131 
33t  LV«ALS(tl>SANE 

CALL  LVOSIN 
C-SET  EQLST  TO  EOCUR 

EOLST  ■ EOCUR  _ 

C'SET  VALUE  OF  EOCUR  TO  THE  PARENT  NAHE  OF  THE  PRESENT  EOCUR 
339  C E0CUR»PR/99*E0CUR*LVNAHE*HaLNAN 

LVVAL-EOCUR 
LVVARC>LVVAL 
LVFUNC«PR 
CALL  LVFINO 

3AA  IFILVVTR  .EO.  -II  60  TO  90 

EOCUR>LVVAL 
LVVAR6*LVVAL 


LVFUNC>LVNAHE 
CALL  LVFINO 

399  HOLNAH«LVVAL 

C-EOCUR  IS  NOT  AN  EO  BLOCK-OONE— RETURN 

ARRAVl«HOLNAH.AND.7T7rOBBtBBBIOBIBtlBOB 
IFIARRAVl.NE.PEOI  RETURN 

C-EOCUR  IS  AN  EO  BLOCK.  SET  PTCUR  TO  PTR  OF  EOCUR 

399  C EOCUR*PTR/ 99* PTCUR 

LVVAL>EOCUR 
LVVARCaLVVAL 
LVFUNC«PTR 
CAU  LVFINO 

399  IFILVVTR  .EO.  -II  60  TO  99 

PTCUR>LVVAL 

C-60  TO  NHERE  6ETTIN6  THE  SUBEO'S  OF  EOCUR  AND  RESUHE  PROCESS  FROH 

C-THERE. 

60  TO  BO 

361  C DESIRED  POINTER  NOT  FOUND  - ERROR 

99  CALL  ERRI9HFETCH,IERRI 
RETURN 

29601  CONTINUE 
LV  l-l 

369  LV  2«B 

LV  3>B 
LV  9-B 
LV  9«l 
LV  6«t 

37B  LV  7-B 

LV  B«0 
LV  9«i 
LVia«l 
LVllM 

379  LV12<I 

LV13<0 
60  TO  29101 
ENO 


STATISTICS 

PR06RAH  LENGTH  lOtlB 

CN  LABELED  COHHON  LENGTH  96B 


913 

36 
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